You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Calculator sample app fails to build in our automated CI (Upgrade) pipeline, but the exact same code builds and runs fine on a normal dev machine. The build machines (CI agents) are simply missing an older Windows SDK (10.0.22621.0) that the Calculator project asks for, so the compiler stops with:
error MSB8036: The Windows SDK version 10.0.22621.0 was not found.
Install the required version of Windows SDK or change the SDK version in the
project property pages or by right-clicking the solution and selecting
"Retarget solution".
This is an environment/agent-provisioning problem, not a bug in the app code or in any React Native / RNW version.
This is NOT a 0.85 regression
In the same CI (Upgrade) run, the Calculator legs fail identically on both:
latest = 0.84.0 (the previous stable), and
preview = 0.85.0-preview.1 (the new one).
Because it fails the same way on the old version too, the 0.85 upgrade did not introduce this. It is a pre-existing infrastructure gap on the agents.
Corroborating evidence that it's the agents (not the code):
Building the committed Calculator/fabric sample locally (RN 0.85.3 + react-native-windows@0.85.0-preview.1, Fabric / New Arch) succeeds in both Debug and Release (x64) — builds, deploys, launches, and renders the full UI. No MSB8036 / SDK-22621 error, because the local machine has SDK 22621 installed.
The Native Module sample (cpp-lib) is 100% green in the same CI run (including all preview legs) — it doesn't pin SDK 22621, so it isn't affected.
Evidence / where to look
Pipeline: CI (Upgrade) — Sample Apps upgrade run.
Run:30375278469 (2026-07-28).
Result: 97 pass / 48 fail. All 48 failures are Calculator legs (cppwinrt / csharp / fabric). Every Native Module (cpp-lib) leg passed.
Error on failing legs:MSB8036: The Windows SDK version 10.0.22621.0 was not found.
Agent image: VS 2026 / Windows Server 2025 agents (these images ship SDK 10.0.26100 but not 10.0.22621).
Impact
CI (Upgrade) shows red for Calculator legs, which is noise on the 0.85 release checklist and can mask real regressions.
No end-user / runtime impact — the shipped Calculator sample builds and runs correctly for anyone whose SDK matches.
Suggested fixes (pick one)
Install Windows SDK 10.0.22621.0 on the CI (Upgrade) agents (restores parity with what the sample targets), or
Retarget the Calculator sample (and/or the upgrade template) to an SDK version the agents already have (e.g., 10.0.26100.0), so it no longer depends on 22621.
Option 1 is the smaller change and keeps the sample as-is; option 2 removes the dependency on a specific older SDK going forward.
Notes
Filed as a follow-up from the 0.85 release validation (tracking issue 0.85 Release Status #16312). Documented there under sample-app CI, now broken out into this dedicated issue so the CI/agent owners can pick it up.
Summary (plain terms)
The Calculator sample app fails to build in our automated CI (Upgrade) pipeline, but the exact same code builds and runs fine on a normal dev machine. The build machines (CI agents) are simply missing an older Windows SDK (10.0.22621.0) that the Calculator project asks for, so the compiler stops with:
This is an environment/agent-provisioning problem, not a bug in the app code or in any React Native / RNW version.
This is NOT a 0.85 regression
In the same CI (Upgrade) run, the Calculator legs fail identically on both:
latest= 0.84.0 (the previous stable), andpreview= 0.85.0-preview.1 (the new one).Because it fails the same way on the old version too, the 0.85 upgrade did not introduce this. It is a pre-existing infrastructure gap on the agents.
Corroborating evidence that it's the agents (not the code):
MSB8036/ SDK-22621 error, because the local machine has SDK 22621 installed.Evidence / where to look
30375278469(2026-07-28).MSB8036: The Windows SDK version 10.0.22621.0 was not found.Impact
Suggested fixes (pick one)
Option 1 is the smaller change and keeps the sample as-is; option 2 removes the dependency on a specific older SDK going forward.
Notes