By default, NuGet packages are being analyzed and issues are reported, in particular whether it follows the conventions (for example, using valid TFMs, placing libraries into a folder under lib etc).
This makes sense for 80% of packages but as we're also using NuGet more and more for tooling (i.e. templates and global tools) those warnings are likely becoming a nuisance. Giving them individual IDs allows suppressing them individually and also give folks a unique way to search for them. So instead of reporting a warning like:
warning : Issue found with package 'ImGui.NET'.
warning : Issue: Assembly outside lib folder.
warning : Description: The assembly 'runtimes/win7-x64/native\cimgui.dll' is not inside the 'lib' folder and hence it won't be added as reference when the package is installed into a project.
warning : Solution: Move it into the 'lib' folder if it should be referenced.
I don't know how these warnings are plugged into VS, but ideally we'd make those guys links so that people can click on them to get more details, instead of spewing the error/warning list with both, the issues as well as well the proposed solutions.
(Filed based on a discussion with @rohit21agrawal)
By default, NuGet packages are being analyzed and issues are reported, in particular whether it follows the conventions (for example, using valid TFMs, placing libraries into a folder under
lib
etc).This makes sense for 80% of packages but as we're also using NuGet more and more for tooling (i.e. templates and global tools) those warnings are likely becoming a nuisance. Giving them individual IDs allows suppressing them individually and also give folks a unique way to search for them. So instead of reporting a warning like:
It should be reporting the issue like:
I don't know how these warnings are plugged into VS, but ideally we'd make those guys links so that people can click on them to get more details, instead of spewing the error/warning list with both, the issues as well as well the proposed solutions.