Add CsWinRT 3 (.1 Windows TFM) assets for CommunityToolkit.WinUI #890

Describe the bug

The issue is written with AI.

CommunityToolkit.WinUI packages need correctly built and packaged Windows .1 TFM assets for CsWinRT 3.

During a separate experiment upgrading to CsWinRT 3, I encountered two distinct package compatibility problems:

1. NU1202 during restore: CommunityToolkit.WinUI.Media 8.3.261026-build.1872 has no compatible Windows .1 assets.
2. Restore succeeds but selects Uno assets: Behaviors, Collections, HeaderedControls, Primitives, Segmented, SettingsControls, and Converters select lib/net9.0 assets referencing Uno.UI, rather than WinAppSDK/WinUI 3-specific assemblies. An isolated Collections restore exited with code 0 but also introduced Uno.WinUI 5.5.87.

The key issue is that a successful NuGet restore does not establish compatibility with CsWinRT 3 if the selected assembly belongs to a different WinUI implementation.

This is an experimental migration issue, not a reported runtime or Native AOT failure in the current application. The existing application continues to use CsWinRT 2.3.1 with a Windows .0 TFM.

Environment

Package sources:

• NuGet.org: https://api.nuget.org/v3/index.json
• CommunityToolkit MainLatest: https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-MainLatest/nuget/v3/index.json

Affected packages and observed behavior

Version distinction: Media 8.3.261026-build.1872 is the explicitly identified experimental failure. The other seven packages are pinned to 8.3.260804-build.1839 in the existing application's project file. Those are exact baseline package versions, but should not be represented as the exact versions of every isolated .1 experiment without the corresponding restore logs.

The reported asset-selection behavior was observed during the .1 experiments. In the affected assemblies, the selected generic net9.0 DLLs reference Uno.UI.

This report intentionally excludes packages maintained elsewhere:

• Labs-Windows: Shimmer, TransitionHelper, DataTable, and TokenView require a separate Labs report.
• CommunityToolkit.Mvvm 8.4.2 is a general-purpose .NET library and is not affected by this WinUI projection issue.
• DevWinUI 10.9.1 is independently maintained. Its .1 asset inspection selected build targets but no compile/runtime DLL; it is not a CommunityToolkit defect.

Steps to reproduce

Create Repro.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0-windows10.0.26100.1</TargetFramework>
    <WindowsSdkPackageVersion>10.0.26100.88-preview</WindowsSdkPackageVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Windows.CsWinRT" Version="3.0.0-preview.261104.1" />
    <PackageReference Include="CommunityToolkit.WinUI.Media" Version="8.3.261026-build.1872" />
  </ItemGroup>
</Project>

Run:

dotnet restore Repro.csproj --force --no-cache `
  --source "https://api.nuget.org/v3/index.json" `
  --source "https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-MainLatest/nuget/v3/index.json"

Actual result: NU1202.

The inspected Media package contains older Windows .0 assets without a matching .1 assembly. Its inspected .NET 9 DLL references WinRT.Runtime, Version=2.2.0.0.

For the second issue, remove the Media reference and test an affected package individually, for example:

<PackageReference Include="CommunityToolkit.WinUI.Collections" Version="8.3.260804-build.1839" />

Restore again using the same sources, then inspect:

obj/project.assets.json

Check the resolved package entry, especially its compile and runtime paths and transitive dependencies.

Observed in the separate .1 experiments:

• NuGet selected lib/net9.0 instead of a Windows App SDK-specific assembly.
• The selected DLLs reference Uno.UI.
• A standalone Collections test returned restore exit code 0 but resolved Uno.WinUI 5.5.87.

These are distinct from a normal Windows .1 compile/runtime asset being selected successfully.

Root technical issue

CsWinRT 3 introduced the Windows .1 TFM revision as an opt-in boundary for a new WinRT projection generation.

Relevant NuGet discussion:

NuGet/Home#14859

A Windows .0 assembly built against CsWinRT 2 should not automatically be treated as an equivalent Windows .1 assembly built against CsWinRT 3.

Likewise, a generic lib/net9.0 asset from an Uno variant must not be treated as evidence that the WinAppSDK variant is supported merely because NuGet considers it framework-compatible.

The source repository's shared build configuration currently exposes Windows App SDK target frameworks ending in .0, through the multi-targeting configuration imported by tooling/ToolkitComponent.SourceProject.props.

The shared WinAppSDK package references also currently use CsWinRT 2.x.

This explains the missing .1 build lane in the current tooling configuration. However, source configuration, newly compiled builds, and already published NuGet assets must be evaluated separately.

Expected behavior

CommunityToolkit should ship genuine Windows .1 assets for CsWinRT 3 consumers, while continuing to support CsWinRT 2 consumers through existing .0 assets.

Requested changes:

1. Add a Windows .1 build lane

   Add net10.0-windows10.0.26100.1 to the appropriate shared component targeting configuration.

   Keep the existing Windows .0 target frameworks.

2. Use matching projection dependencies

   The new lane should use CsWinRT 3.0.0-preview.261104.1, Windows SDK projection 10.0.26100.88-preview, and a compatible WinAppSDK/WinUI dependency graph, or appropriate later compatible versions.

   This must be conditional on the new lane, without changing the projection generation of existing .0 packages.

3. Rebuild dependent components consistently

   Media references the Animations and Extensions projects.

   These dependencies also require compatible .1 builds and package assets; mixing old .0 projected assemblies with newly compiled .1 components is not an adequate solution.

4. Publish correctly targeted NuGet assets

   Provide the newly compiled Windows DLLs under:

   lib/net10.0-windows10.0.26100.1/
   

   Include correct compile/runtime assets and matching dependency groups.

   Retain existing .0 assets for legacy consumers.

5. Validate the selected assets, not just restore success

   Test both .0 and .1 consumers, inspect the resolved compile/runtime assets and transitive dependencies, and ensure a Windows .1 consumer does not silently select Uno implementations.

   Build and exercise representative WinUI controls, and validate Native AOT publishing where applicable.

Pure C# controls should not be required to introduce WinMD files solely for this migration. Rebuilding their managed assemblies against the correct projection generation is sufficient unless a component actually exposes a Windows Runtime ABI.

What should not be considered a fix

• Copying an old CsWinRT 2 DLL into a .1 asset directory.
• Using AssetTargetFallback to force cross-generation compatibility.
• Forcing consumers to downgrade to CsWinRT 2.
• Treating a successful restore that selects lib/net9.0 Uno assets as WinAppSDK support.
• Claiming compatibility based only on source changes without testing newly built and published NuGet packages.

Expected outcome

A CsWinRT 3 application targeting net10.0-windows10.0.26100.1 should restore the appropriate Windows-specific CommunityToolkit assemblies, with consistent projection dependencies, while existing CsWinRT 2 consumers retain their supported .0 assets.

This report concerns package restore and asset-selection compatibility. It does not claim that the currently shipping Native AOT application is broken.

Screenshots

No response

Code Platform

• UWP
• WinAppSDK / WinUI 3
• Web Assembly (WASM)
• Android
• iOS
• MacOS
• Linux / GTK

Windows Build Number

• Windows 10 1809 (Build 17763)
• Windows 10 1903 (Build 18362)
• Windows 10 1909 (Build 18363)
• Windows 10 2004 (Build 19041)
• Windows 10 20H2 (Build 19042)
• Windows 10 21H1 (Build 19043)
• Windows 10 21H2 (Build 19044)
• Windows 10 22H2 (Build 19045)
• Windows 11 21H2 (Build 22000)
• Windows 11 22H2 (Build 22621)
• Windows 11 23H2 (Build 22631)
• Windows 11 24H2 (Build 26100)
• Windows 11 25H2 (Build 26200)
• Windows 11 26H1 (Build 28000)
• Other (specify)

Other Windows Build number

No response

App minimum and target SDK version

• Windows 10, version 1809 (Build 17763)
• Windows 10, version 1903 (Build 18362)
• Windows 10, version 1909 (Build 18363)
• Windows 10, version 2004 (Build 19041)
• Windows 10, version 2104 (Build 20348)
• Windows 11, version 22H2 (Build 22000)
• Windows 11, version 24H2 (Build 26100)
• Windows 11, version 25H2 (Build 26200)
• Windows 11, version 26H1 (Build 28000)
• Other (specify)

Other SDK version

No response

Visual Studio Version

2026, Insiders

Visual Studio Build Number

Insiders [12328.396]

Device form factor

Desktop

Additional context

No response

Help us help you

No, I'm unable to contribute a solution.