Support CsWinRT 3.0 multi-targeting and WindowsSdkPackageMinimumRevision #50264

dsplaisted · 2025-08-14T17:43:43Z

This is a continuation of #49721

This PR allows multi-targeting CsWinRT 3.0, by leveraging the build number of the target Windows SDK.
That is, e.g.:

net10.0-windows10.0.22621.0 ---> CsWinRT 2.x
net10.0-windows10.0.22621.1 ---> CsWinRT 3.0

In the implementation, rather than using separate ref packs for CSWinRT 2 and 3, which the previous PR did, this PR uses profiles of the Microsoft.Windows.SDK.NET.Ref framework reference to differentiate between the versions of CSWinRT.

This also adds support for a WindowsSdkPackageMinimumRevision property.

…iate between CSWinRT 2 and 3

src/Tasks/Microsoft.NET.Build.Tasks/ResolveRuntimePackAssets.cs

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Windows.props

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Windows.targets

src/Layout/redist/targets/GenerateBundledVersions.targets

test/Microsoft.NET.Build.Tests/GivenThatWeWantToBuildAWindowsDesktopProject.cs

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.TargetFrameworkInference.targets

dsplaisted · 2025-08-20T21:28:41Z

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets

+      <_SupportedPlatformCompatibleVersions Include="@(SdkSupportedTargetPlatformVersion)"
+                                            Condition=" %(Identity) != '' and '%(SdkSupportedTargetPlatformVersion.NormalizedSupportedTargetPlatformVersion)' == '' and $([MSBuild]::VersionLessThanOrEquals(%(Identity), $(TargetPlatformVersion))) " />
+      <_SupportedPlatformCompatibleVersions Include="@(SdkSupportedTargetPlatformVersion->'%(NormalizedSupportedTargetPlatformVersion)')"
+                                            Condition=" '%(SdkSupportedTargetPlatformVersion.NormalizedSupportedTargetPlatformVersion)' != '' and $([MSBuild]::VersionLessThanOrEquals('%(SdkSupportedTargetPlatformVersion.NormalizedSupportedTargetPlatformVersion)', $(TargetPlatformVersion))) " />


Will this result in duplicate _SupportedPlatformCompatibleVersions items, since we get one from the .0 SdkSupportedTargetPlatformVersion and one from the .1 one. If so, should we fix that?

When _SupportedPlatformCompatibleVersions is used right below, it is used as @(_SupportedPlatformCompatibleVersions->Distinct() so that removes the duplicates.

dsplaisted · 2025-08-20T21:31:37Z

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets

+  <PropertyGroup>
+    <!-- If the Windows targets wasn't called to default it, then just default it to the TargetPlatformVersion. -->
+    <EffectiveTargetPlatformVersion Condition="'$(EffectiveTargetPlatformVersion)' == ''">$(TargetPlatformVersion)</EffectiveTargetPlatformVersion>
+  </PropertyGroup>


It looks like the EffectiveTargetPlatformVersion is set in Microsoft.NET.TargetFrameworkInference.targets, which is unconditionally imported. So do we need this here? Can we make it so that TargetFrameworkInference always sets this property instead?

I initially made Microsoft.NET.TargetFrameworkInference.targets always default it, but then I ran into issues with Directory.Build.Targets can set WindowsPlatformVersion and that was after the TargetFrameworkInference.targets, so I had to handle that case in Microsoft.Net.Windows.targets which is based on EffectiveTargetPlatformVersion not being set. Given the use of Directory.Build.targets which probably can also be used to set the platform, I put this here to catch such scenarios.

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.TargetFrameworkInference.targets

...sks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.WindowsSdkSupportedTargetPlatforms.props

dsplaisted · 2025-08-20T21:58:39Z

test/Microsoft.NET.Build.Tests/GivenThatWeWantToBuildAWindowsDesktopProject.cs

        }

+        [WindowsOnlyFact]
+        public void ItWarnsWhenBuildingAProjectTargetingCsWinRT3_0()


We haven't published a Ref pack with the new CSWinRT profiles yet, so these projects will be referencing a profile which doesn't exist in the ref pack. I would have expected that to error but I guess maybe it silently just doesn't reference any assemblies.

What should the behavior be in this case?

I will confirm locally what happens but I would be fine if the behavior is basically no profiles get included and thereby no assemblies referenced or if it errored.

Looks like behavior is no profiles get included. It does error due to CsWinRTGen missing which this test doesn't run into due to CsWinRTGenerateInteropAssembly is set to false. I assume this behavior is fine.

Co-authored-by: Daniel Plaisted <[email protected]>

Copilot prompt #1: Replace the #class:'Microsoft.DotNet.Build.Tasks.OverrideAndCreateBundledNETCoreAppPackageVersion':1164-10242 Task. The new version should take as parameters the path to the stage 0 bundled versions file as well as the version from stage 2. It should copy some version numbers from items in the stage 0 version to the stage 2 version, and then save the updated stage 2 version. It should update items where the TargetFramework metadata is not the latest target framework supported. There are multiple item types that need to be updated, and they need to be matched on specific metadata. KnownFrameworkReference: match on Include, TargetFramework metadata. Update LatestRuntimeFrameworkVersion and TargetingPackVersion KnownAppHostPack: match on Include, TargetFramework metadata. Update AppHostPackVersion KnownCrossgen2Pack: match on Include, TargetFramework. Update Crossgen2PackVersion KnownILCompilerPack: match on Include, TargetFramework. Update ILCompilerPackVersion KnownRuntimePack: match on Include, TargetFramework, RuntimePackLabels. Update LatestRuntimeFrameworkVersion KnownILLinkPack: match on Include, TargetFramework. Update ILLinkPackVersion. If there is more than one match based on the specified metadata, generate an error. For the metadata which is not used to match and is not updated, if the value differs between the stage 0 and stage 2 versions, log a message. Copilot prompt dotnet#2: Don't look at just the first ItemGroup in each file, load items from all ItemGroups found. When looking for the latest target framework, use the NuGetFramework class to parse the TargetFramework values, and to compare them.

dsplaisted · 2025-09-05T20:50:29Z

@marcpopMSFT I've pushed changes to this PR that significantly change OverrideAndCreateBundledNETCoreAppPackageVersion, which you enabled in #50418.

The problem with the previous logic is that it basically uses the stage 0 bundled versions for stage 2 with some version numbers updated. This was necessary when the real bundled versions was in the separate installer repo. Now that the repos are merged though, we generate the fully correct bundled versions file in the SDK. If we replace that with the stage 0 version, then when we make changes to what's in the bundled versions file, they won't be available for tests until the updates flow back through stage 0.

So what the logic now does is preserve most of what is in the newly built bundled versions file, and only copy over version numbers for downlevel runtimes from stage 0. I think that should solve the issues.

dsplaisted · 2025-09-05T22:07:31Z

/azp run

azure-pipelines · 2025-09-05T22:07:45Z

Azure Pipelines successfully started running 1 pipeline(s).

joeloff · 2025-09-15T18:26:02Z

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Windows.targets

-    <FrameworkReference Condition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp' and $([MSBuild]::VersionGreaterThanOrEquals($(TargetFrameworkVersion), '8.0')) and '$(TargetPlatformIdentifier)' == 'Windows' and '$(UseUwp)' == 'true' " Include="Microsoft.Windows.SDK.NET.Ref.Xaml" />
+  <ItemGroup Condition=" '$(IncludeWindowsSDKRefFrameworkReferences)' == 'true' And
+                          '$(TargetFrameworkIdentifier)' == '.NETCoreApp' and $([MSBuild]::VersionGreaterThanOrEquals($(TargetFrameworkVersion), '8.0')) and '$(TargetPlatformIdentifier)' == 'Windows' and '$(UseUwp)' == 'true' ">
+    <FrameworkReference Condition="'$(_TargetPlatformVersionUsesCsWinRT3)' != 'true'"


Should one of these be for Microsoft.Windows.SDK.NET.Ref.CsWinRT3.Windows, or is the UseUwp only applicable to XAML and this pulls in the 2.0 and 3.0 Xaml reference?

UseUwp is only applicable to the Xaml profile which has the inbox XAML APIs.

joeloff · 2025-09-15T20:10:18Z

src/Tasks/sdk-tasks/OverrideAndCreateBundledNETCoreAppPackageVersion.cs

 using System.Xml.Linq;
 using Microsoft.Build.Framework;
 using Microsoft.Build.Utilities;
-using NuGet.Versioning;
+using System.Collections.Generic;
+using NuGet.Frameworks;


nit: sort usings

joeloff · 2025-09-15T20:14:52Z

test/Microsoft.NET.Build.Tests/GivenThatWeWantToBuildAWindowsDesktopProject.cs

+                {
+                    ["Program.cs"] = """
+                    #if CSWINRT3_0
+                    #error CSWINRT3_0 is defined


Would this type of test catch situations where a package has the wrong minor version, for example, something that should have been versioned with .1 was versioned with .0 so the targets treat it as a 2.0 package, but it's actually a 3.0 package?

This test is more if you are building a project with .0, make sure that none of the CSWINRT_3 things are defined.

Sergio0694 and others added 17 commits August 8, 2025 12:42

Support '1.' TFM for CsWinRT 3.0

1fa8f16

Add 'UsingPreviewCsWinRT3_0Feature' warning

2ad9302

Add test for new preview warning

c256006

Run 'msbuild /t:UpdateXlf'

4821072

Update 'TargetPlatformVersion' parsing

aa2210e

Update targeting pack selection logic

ba90d36

Update '_WarnForCsWinRT3_0PreviewFeatureEnabled'

a6e227a

Define 'CSWINRT3_0' for CsWinRT 3.0

4d465e6

Add unit tests

676ece8

Revert incorrect 'Strings.resx' change

0c68835

Update .xlf files

58c260c

Fix parsing normalized SDK version

d8d8cb0

Fix framework references creation for '.1' TFM

fd4f274

Add unit tests for normalized defines

983f973

Merge branch 'main' into user/sergiopedri/cswinrt3-multi-targeting

0e83d36

Switch to using profiles in the same framework reference to different…

b38c092

…iate between CSWinRT 2 and 3

Add support for WindowsSdkPackageMinimumRevision

b622290

github-actions bot added the Area-Infrastructure label Aug 14, 2025

manodasanW and others added 3 commits August 14, 2025 18:43

Fix included profiles

c29c79e

Add CSWinRT 2 and 3 multi-targeting test

415c772

Don't normalize to .0 TargetPlatformVersion revision for CSWinRT 3

d7126cc

manodasanW reviewed Aug 18, 2025

View reviewed changes

src/Tasks/Microsoft.NET.Build.Tasks/ResolveRuntimePackAssets.cs Outdated Show resolved Hide resolved

manodasanW reviewed Aug 19, 2025

View reviewed changes

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Windows.props Outdated Show resolved Hide resolved

manodasanW reviewed Aug 19, 2025

View reviewed changes

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Windows.targets Outdated Show resolved Hide resolved

This was referenced Aug 19, 2025

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

manodasanW added 2 commits August 18, 2025 19:09

Fix profile names

93d669f

Normalize implicit define

ca298da

Sergio0694 mentioned this pull request Aug 19, 2025

Add support for CsWinRT 3.0 multi-targeting via Windows SDK build number #49721

Closed

Sergio0694 reviewed Aug 19, 2025

View reviewed changes

src/Layout/redist/targets/GenerateBundledVersions.targets Show resolved Hide resolved

src/Layout/redist/targets/GenerateBundledVersions.targets Show resolved Hide resolved

test/Microsoft.NET.Build.Tests/GivenThatWeWantToBuildAWindowsDesktopProject.cs Outdated Show resolved Hide resolved

Fix SupportedOSPlatformVersion and tests

95fdd4b

dsplaisted commented Aug 19, 2025

View reviewed changes

src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.TargetFrameworkInference.targets Outdated Show resolved Hide resolved

manodasanW added 2 commits August 19, 2025 16:39

Fix tests and always set EffectiveTargetPlatformVersion

0787215

Fix TargetPlatformVersion being set in Directory.Build.targets

2dffc35

dsplaisted changed the base branch from main to release/10.0.1xx August 20, 2025 21:22

dsplaisted commented Aug 20, 2025

View reviewed changes

manodasanW and others added 4 commits August 20, 2025 15:23

Apply suggestion from @dsplaisted

ffbdf9e

Co-authored-by: Daniel Plaisted <[email protected]>

Fix typo

8d29560

Use version parse instead

62fa6b6

Add tests and additional error case for WindowsSdkPackageMinimumRevision

09e3f53

dsplaisted marked this pull request as ready for review August 27, 2025 17:44

dsplaisted requested a review from a team August 27, 2025 17:45

dsplaisted added 4 commits September 3, 2025 21:04

Collect binlog for test

45d1d9b

Murge upstream changes

0bf81da

Fixup/edits to copilot code

f615526

joeloff reviewed Sep 15, 2025

View reviewed changes

joeloff approved these changes Sep 16, 2025

View reviewed changes

Remove unnecessary usings

670d7fc

dsplaisted merged commit e61f87b into dotnet:release/10.0.1xx Sep 16, 2025
27 checks passed

Copilot AI mentioned this pull request Oct 2, 2025

Use Version.TryParse to avoid exceptions when calling [System.Version]::Parse dotnet/msbuild#12591

Open

Support CsWinRT 3.0 multi-targeting and WindowsSdkPackageMinimumRevision #50264

Support CsWinRT 3.0 multi-targeting and WindowsSdkPackageMinimumRevision #50264

Uh oh!

Conversation

dsplaisted commented Aug 14, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dsplaisted commented Sep 5, 2025

Uh oh!

dsplaisted commented Sep 5, 2025

Uh oh!

azure-pipelines bot commented Sep 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!