Upgrade GitHub Actions runner images to windows-2025 and install Windows SDKs#852
Open
Arlodotexe wants to merge 2 commits into
Conversation
Arlodotexe
added
external ⤴️
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
During the .NET 10 SDK upgrade work, CI started requiring the Visual Studio 2026 / MSBuild 18 toolchain.
Visual Studio 2026 18.0 is the release that added .NET 10 support, but the
windows-2022runner image only includes Visual Studio 2022 / MSBuild 17.That showed up in the .NET 10 upgrade CI runs when
microsoft/setup-msbuildwasn't able to resolve MSBuild 18 onwindows-2022, alongside the parallel tooling work in Tooling #309.During the follow-up runner investigation, we confirmed why the workflows had been pinned to
windows-2022in the first place. GitHub changedwindows-latestto resolve towindows-2025on September 30, 2025, and the Windows Server 2025 hosted image no longer included the older Windows SDKs our builds depended on. That broke CI at the time, so the repos were pinned back towindows-2022in Windows #737, Labs #743, and Tooling #296.Labs issue #741 tracked the original runner-image fallout.
Problem
During the .NET 10 upgrade, the old mitigation became the new blocker.
windows-2022still avoids the missing-SDK issue, but it cannot provide the VS2026/MSBuild 18 toolchain required by .NET 10.windows-2025provides the required VS2026/MSBuild 18 toolchain, but it reintroduces the missing Windows SDK issue that caused the original runner pin.During the compatibility review, we also confirmed that changing the Windows target requirements is not the right fix. The shared tooling configuration still preserves older Windows target compatibility, including
TargetPlatformMinVersion10.0.17763.0. Raising those requirements would turn a CI image dependency into a consumer-facing compatibility change.Solution
During the tooling update, we brought back the small
Install-WindowsSdk.ps1script from the 7x Windows Community Toolkit build scripts.During the workflow update, the CI jobs were moved back to
windows-2025and a newInstall Windows SDKsstep was added beforemicrosoft/setup-msbuild.That gives CI both sides of the requirement:
It also makes the SDK dependency explicit instead of depending on whichever SDK versions happen to be preinstalled on the runner image.
A more polished end-user SDK detection/install flow can be handled separately; this PR is intentionally scoped to unblocking CI on
windows-2025.Prerequisites to closing this PR: