Upgrade GitHub Actions runner images to windows-2025 and install Windows SDKs

[Arlodotexe]

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-2022 runner image only includes Visual Studio 2022 / MSBuild 17.

That showed up in the .NET 10 upgrade CI runs when microsoft/setup-msbuild wasn't able to resolve MSBuild 18 on windows-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-2022 in the first place. GitHub changed windows-latest to resolve to windows-2025 on 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 to windows-2022 in 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-2022 still avoids the missing-SDK issue, but it cannot provide the VS2026/MSBuild 18 toolchain required by .NET 10. windows-2025 provides 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 TargetPlatformMinVersion 10.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.ps1 script from the 7x Windows Community Toolkit build scripts.

During the workflow update, the CI jobs were moved back to windows-2025 and a new Install Windows SDKs step was added before microsoft/setup-msbuild.

That gives CI both sides of the requirement:

• The current hosted image with VS2026/MSBuild 18 for .NET 10
• The explicit Windows SDK installation needed to preserve existing Windows target compatibility.

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.

[Avid29]

Do we want to consider just using windows-latest?

I know this would mean the runner could swap out from under us and disrupt the CI, but they already modify named images, and in this case an issue would more likely represent a deprecation that we should migrate from.

[Arlodotexe]

We pinned the runner because we haven't had the bandwidth to be proactive about moving ourselves to the latest as it changed under us.

For now, according to the github runner images docs, we have until the next GA release to get off of windows-2022 and onto windows-2025, so that we're not rug-pulled regarding windows-2022 for the whole image when the next windows-latest GA release happens after windows-2025.

The full window is between either:

• Reactively catching-up so we don't find ourselves using EOL runners
• Proactively updating (to the extent we can) so that we stay ahead of whatever the next windows-latest release is.

We're currently somewhere in the middle by pinning to windows-2025-- not at risk of using EOL, not at risk of using newer images with missing dependencies.

Regarding the way github updates the dependencies in the runner itself, they only explicitly spell out their deprecation policy (dependencies can be removed when they're EOL) but past behavior heavily implies that they don't intentionally remove dependencies on existing runners otherwise.

Let's stay pinned to a specific runner version for now.