Nuget packages resolving differently in Visual Studio v.s. dotnet cli

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[regression] [worked-in:17.11.6]
After I upgraded to VS 17.12, I started getting errors in WinUI library projects that they are referencing vulnerable packages. I filed an issue in the NuGet repo, thinking that it was an issue with the new NuGet algorithm.

It turns out that it works fine with dotnet cli, where the restore behavior is different for some reason. nkolev92 on the NuGet team looked into the issue and suggested that I file an issue here, and he summarized his findings in this comment, suggesting I post the issue here.

The important bit of his findings was:

In Visual Studio, the RuntimeIdentifiers property is set to win-arm64;win-x64;win-x86 for WinUI project. This causes a discrepancy between Visual Studio and CLI restore. This is something we should report to WinUI. Please file the issue in DeveloperCommunity. Feel free to link it here, and I’ll make sure the correct team gets this feedback.
Note that this is not a regression from 17.11, but I don’t think it’s a wanted behavior.

You can review that issue to get full context of the problem.

---

Original Comments

Feedback Bot on 11/17/2024, 06:35 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Feedback Bot on 11/19/2024, 09:49 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

---

Original Solutions

Mike Marynowski solved on 11/15/2024, 08:35 PM, undefined votes:

Add <EnableMsixTooling>true</EnableMsixTooling> to the library csproj files.

Feedback Bot solved on 11/18/2024, 08:52 PM, undefined votes:

Thanks for taking the time to report this issue! It seems to us that it’s describing the same thing as another one. We’ve closed this one as a duplicate and transferred all votes from this ticket to the other one. Please follow along on the linked ticket to communicate with the team, see updates on status, and help provide any needed diagnostic info. For more information, see our issue reporting guidelines.

Happy coding!

Mike Marynowski on 11/18/2024, 09:43 PM:

The issue was originally reported to nuget and members of that team did some more digging. This issue needs to be looked at and addressed by the WinUI project team, as indicated in what the OP above says.