Background

On September 30, 2024, GitHub changed the windows-latest runner label to point to windows-2025 (previously windows-2022). The Windows Server 2025 runners removed all preinstalled Windows SDKs except the latest version.

This change immediately broke all CI builds for CommunityToolkit/Labs-Windows. Our builds require two specific Windows SDK versions:

• SDK 17763 for UWP (TargetFramework)
• SDK 19041 for WinAppSDK (TargetFramework)

Upgrading these TFM versions would force all consumers to update, so we maintain these specific SDK requirements to preserve backward compatibility.

During the October 2, 2025 WCT sync, we identified a mitigation strategy:

1. Try windows-2022 to test if previous D drive disk space issues are resolved
2. Use windows-2022-large as a fallback/prep if standard runner has issues

Problem

Current Impact:

• All CI builds failing with SDK-related errors
• Cannot build or test any Labs components
• Blocks all PR validation and releases
• Weekly releases cannot be published
• Component graduation to main repo blocked

Root Cause:

• windows-latest now resolves to windows-2025
• Windows 2025 runners only include the latest Windows SDK
• Our builds require SDK 17763 (UWP) and SDK 19041 (WinAppSDK)
• These specific SDK versions are no longer present on windows-2025 runners
• Cannot upgrade TFMs without forcing all consumers to update

Issue: #741

Solution

Pin all Windows runner specifications to windows-2022:

Changes:

• windows-latest → windows-2022 (2 jobs)
  • Xaml-Style-Check job
  • sign job
• windows-latest-large → windows-2022 (2 jobs)
  • build job
  • package job
• Tooling submodule updated with same fix

Strategy:

1. First pass: Test windows-2022 for ALL jobs to verify if previous D drive disk space issues are resolved
2. If builds succeed: Confirms windows-2022 is sufficient for all workflows
3. If disk space errors occur: Will escalate to windows-2022-large for build/package jobs (which specifically addresses out of disk space errors from missing D drive)

Jobs Updated:

1. Xaml-Style-Check - Quick XAML formatting validation
2. build - Component builds for UWP and WinAppSDK
3. package - NuGet package creation for all components
4. sign - Package signing for releases

Testing:

• CI will run on this PR to validate all build configurations
• Success confirms SDK availability and build matrix compatibility
• If builds fail, we'll evaluate escalating all jobs to -large runners

Closes

Fixes #741