Upgrade to .NET 10, runner images to windows-2025, use only 26100 Windows SDK

[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.

Prerequisites to closing this PR:

• Blocked by Upgrade GitHub Actions runner images to windows-2025 and install Windows SDKs Tooling-Windows-Submodule#312

[riverar]

#737 indicates you're keeping these old SDKs around because you target them via TargetFramework but that normally doesn't require the SDKs to be installed. Is there something else keeping you on the older SDKs?

[Arlodotexe]

#737 indicates you're keeping these old SDKs around because you target them via TargetFramework but that normally doesn't require the SDKs to be installed. Is there something else keeping you on the older SDKs?

"TargetFramework" mention in 737 is a mistake-- the restriction comes from the TargetPlatformVersion. I've fixed the text.

[riverar]

@Arlodotexe That shouldn't require the physical Windows SDK 17134 either though.

[Arlodotexe]

After various testing and analyzing what was tried with the community, we've come to the conclusion that there's something wrong with the ISO-based Windows SDK installer that prevents the SDK from being used to build UWP/netx (UWP with modern .NET).

Our options for Windows SDKs are now limited to only what we use out of the provided SDKs from the GitHub Actions runner image, which is only 26100.

This means instead of installing the 19041 SDK (there's no official CI-friendly method) we'll need to upgrade WASDK from 19041 to 26100 for the Target version, while keeping the min version as-is.

We also need to know whether this will require updating TFMs so that it can be disclosed when the update is released so consumers aren't surprised when they update the toolkit and their app breaks from TFM incompatability.