Hope that the future can in Nuget package management page through the UI update Microsoft.Windows.SDK.NET.Ref package

[Gaoyifei1011]

Description

Hope that the future can in Nuget package management page through the UI update Microsoft.Windows.SDK.NET.Ref package
希望未来能在 Nuget 包管理页面中通过 UI 更新 Microsoft.Windows.SDK.NET.Ref 包

After updating to CsWinRT 2.1.X, we found that the Microsoft.Windows.SDK.NET.Ref framework package will also be updated with the version of CsWinRT, however if we want to know the latest version of Microsoft.Windows.SDK.NET.Ref, we need to manually search and modify the 10.0.26100.45 property value, which is no longer very convenient. I hope that the .NET Team,CsWinRT team can communicate with the Visual Studio team, and you can add a separate display of the content of the framework package on the Nuget package management page, and you can follow the ordinary Nuget package to update it on the Nuget package management page
在更新到 CsWinRT 2.1.X 后，我们发现Microsoft.Windows.SDK.NET.Ref 框架包也会随着 CsWinRT 的版本进行更新，然而如果我们想了解 Microsoft.Windows.SDK.NET.Ref 的最新版本，需要手动搜索并修改 csproj 下的 10.0.26100.45 属性值，这已操作不太方便。希望 .NET 团队、 CsWinRT 团队能和 Visual Studio 团队能沟通一下，可以在 Nuget 包的管理页面添加一个单独显示框架包的内容，可以跟随普通的 Nuget 包在 Nuget 包管理页面进行更新

Reproduction Steps

See Description

Expected behavior

Can add a separate display of the content of the framework package on the Nuget package management page, and you can follow the ordinary Nuget package to update it on the Nuget package management page
可以在 Nuget 包的管理页面添加一个单独显示框架包的内容，可以跟随普通的 Nuget 包在 Nuget 包管理页面进行更新

Actual behavior

Manually search for the Microsoft.Windows.SDK.NET.Ref package and manually modify the 10.0.26100.45 property in csproj
手动搜索 Microsoft.Windows.SDK.NET.Ref 包，并在 csproj 中手动修改 10.0.26100.45 属性

Regression?

None

Known Workarounds

None

Configuration

.NET 9 Preview 7
Windows 11 26100
X64
None

Other information

None

[huoyaoyuan]

This belongs to the sdk/cswinrt repo rather than runtime repo.

These type of reference is <FrameworkReference> instead of <PackageReference>. They are intentionally un-versioned and aligns with the SDK. They are expected be kept in sync with SDK version, and the WindowsSdkPackageVersion property is a workaround for special situations. It's the unaligned release of WinAppSDK forces everyone to use the special workaround.

The current logic is very unfriendly with UI. It's not setting metadata on any FrameworkReference item, but a property that gets injected into FrameworkReference resolution logic.

[Gaoyifei1011]

This belongs to the sdk/cswinrt repo rather than runtime repo.

These type of reference is instead of . They are intentionally un-versioned and aligns with the SDK. They are expected be kept in sync with SDK version, and the property is a workaround for special situations. It's the unaligned release of WinAppSDK forces everyone to use the special workaround.<FrameworkReference>``<PackageReference>``WindowsSdkPackageVersion

The current logic is very unfriendly with UI. It's not setting metadata on any item, but a property that gets injected into resolution logic.FrameworkReference``FrameworkReference

CsWinRT Answering
microsoft/CsWinRT#1786

[huoyaoyuan]

It's an unofficial reply about the limitation to specify minimal required .NET SDK.

Components shipped with SDK are special. It may not be worth to build UI for special circumstances, at least it's expected to be special to specify their versions.

[dotnet-policy-service]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!

[Gaoyifei1011]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!

However, I don't think this issue should be closed, and the VS team, the CsWinRT team, and the .NET team should be contacted to deal with this tricky problem and work together to improve the developer experience
然而我认为这个问题不应该被关掉，应该联系 VS 团队，CsWinRT 团队，.NET 团队一块处理一下这个棘手的问题，共同优化一下开发者的体验

[huoyaoyuan]

This is not quite actionable. It's an expected corner case with specialized workaround. Building more support for this corner case will add very little value, with even more effort than regular case.