NuGet Product(s) Affected
MSBuild.exe
Current Behavior
Today, someone can target net10.0-windows10.0.17763.0 or similar OS version TFM and they will get access to the CsWinRT 2.x generated Windows SDK projection and libraries will be able to ship their own WinRT projections generated by CsWinRT using that or similar TFM.
We, the CsWinRT team, have been working on CsWinRT 3.0, which is going to be a breaking change and want to provide libraries and apps a way to opt-in to the new way we will be generating WinRT projections. To allow for that,
in .NET 10, we worked with the .NET SDK team to add new Windows OS version TFMs with a .1 revision (i.e. net10.0-windows10.0.17763.1). Using the .1 revision of the TFM will imply this is a CsWinRT 3.0 or later projection and provide a way for libraries and apps to opt-in. The revision in the Windows OS version of the TFM in the past has been 0 and other values were not used.
We are seeing that when a NuGet provides the exact TFM version with the .1 or .0 that the app targets, everything is fine. But when the app targets a much later version like net10.0-windows10.0.22621.0 while the NuGet provides net10.0-windows10.0.17763.1, the nearest TFM version behavior of NuGet kicks in and then currently uses regular OS version comparison which can lead to a CsWinRT 2.x targeted app referencing a CsWinRT 3.0 projection or vice versa.
Desired Behavior
The behavior we desire is that NuGet instead takes into account the revision when doing the nearest TFM version behavior and if an app is targeting the .0 revision for the OS version in the TFM, then only packages with .0 for the OS version or no OS version are the ones that it matches with. Similarly if an app is targeting the .1 revision for the OS version in the TFM, then only packages with .1 for the OS version or no version are the ones that it matches with.
To say it another way, if an app is targeting .0, it shouldn't choose a .1 TFM and if an app is targeting .1, it shouldn't choose a .0 TFM.
Additional Context
CsWinRT 3.0 is currently in preview, so there aren't any NuGet packages currently shipping with the new .1 TFM. We were working on the first one to do a preview with that package when we discovered this issue. This also seems to impact project references that are multi-targeting as it seems the task from NuGet is used for the nearest TFM version resolution.
NuGet Product(s) Affected
MSBuild.exe
Current Behavior
Today, someone can target
net10.0-windows10.0.17763.0or similar OS version TFM and they will get access to the CsWinRT 2.x generated Windows SDK projection and libraries will be able to ship their own WinRT projections generated by CsWinRT using that or similar TFM.We, the CsWinRT team, have been working on CsWinRT 3.0, which is going to be a breaking change and want to provide libraries and apps a way to opt-in to the new way we will be generating WinRT projections. To allow for that,
in .NET 10, we worked with the .NET SDK team to add new Windows OS version TFMs with a .1 revision (i.e.
net10.0-windows10.0.17763.1). Using the .1 revision of the TFM will imply this is a CsWinRT 3.0 or later projection and provide a way for libraries and apps to opt-in. The revision in the Windows OS version of the TFM in the past has been 0 and other values were not used.We are seeing that when a NuGet provides the exact TFM version with the .1 or .0 that the app targets, everything is fine. But when the app targets a much later version like
net10.0-windows10.0.22621.0while the NuGet providesnet10.0-windows10.0.17763.1, the nearest TFM version behavior of NuGet kicks in and then currently uses regular OS version comparison which can lead to a CsWinRT 2.x targeted app referencing a CsWinRT 3.0 projection or vice versa.Desired Behavior
The behavior we desire is that NuGet instead takes into account the revision when doing the nearest TFM version behavior and if an app is targeting the .0 revision for the OS version in the TFM, then only packages with .0 for the OS version or no OS version are the ones that it matches with. Similarly if an app is targeting the .1 revision for the OS version in the TFM, then only packages with .1 for the OS version or no version are the ones that it matches with.
To say it another way, if an app is targeting .0, it shouldn't choose a .1 TFM and if an app is targeting .1, it shouldn't choose a .0 TFM.
Additional Context
CsWinRT 3.0 is currently in preview, so there aren't any NuGet packages currently shipping with the new .1 TFM. We were working on the first one to do a preview with that package when we discovered this issue. This also seems to impact project references that are multi-targeting as it seems the task from NuGet is used for the nearest TFM version resolution.