I think this may be a good opportunity to introduce the concept of analysis level for NuGet warnings, or at minimum, add a way to enable warnings that are gated per framework for all frameworks instead.
Scenario 1:
For the purposes of pruning, we introduced a few warnings
- NU1510 - https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1510 - Can't prune a direct reference
- NU1511 - https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1511 - Can't prune a project reference
These warnings, especially, the NU1510 are particularly likely to happen, I wouldn't be shocked if it goes into a full percent of projects that end up with these warnings. With our volume, that's a large number of customers. Because of that we decide to gate NU1510 and NU1511 on the adoption of .NET 10 framework. This is a pattern that will be repeating over the years. We'll introduce what we consider necessary warnings that will be gated on the adoption of the new framework matching the SDK.
The thing I want to focus is that we consider these warnings necessary. By gating these warnings on the usage of a new framework, we make it difficult for someone like the dotnet org, or NuGet org who'd actually like to get these warnings and address them immediately. We'd like to constantly address these concerns.
Scenario 2:
Pack warnings - There are more than 30+ pack warnings that are used. Majority of them are useful in every case, but we do have scenarios for warnings that'd only be useful in some cases. Take NuGet/Home#13633 for example. We'd like to add an opt-in warning for readme to allow the runtime repo to enforce readmes across the whole repo at pack time.
Scenario 3: The same reasoning applies to the NuGet Audit warnings, but those already have their own control properties.
The idea here is that we need a means to control this. Fortunately there are some precedents that we can learn from!
AnalysisLevel - https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#analysislevel
The compiler has the concept of an analysis level for compile time warnings. The default value is latest but other values include 9.0, 8.0 etc, where the numbers match the .NET version they were released with.
AnalysisMode - https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#analysismode
This is the other property that control these warnings and it has values such as none, minimum, default, all etc.
SdkAnalysisLevel - https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#sdkanalysislevel
This serves as a kind of umbrella property and it may override AnalysisLevel (I think, @baronfel can help confirm).
Idea 1:
The scenarios for the compiler are significantly more complicated than what NuGet has in restore and pack.
I think on the NuGet side, we can get away with 1 or 2 property (depending on if we wanted pack separate), named
NuGetAnalysisMode and have 3 values, all, minimum and none. I'm not 100% set on the naming. We do have nopackageanalysis as a means to disable pack warnings, so if we wanted to have Restore and Pack specific analysis modes that'd be fine.
The benefit here is that we can safely keep adding new warnings behind opt-in and allow customers who want to be more aggressive stay on latest.
Idea 2:
Add a means to "enable" these warnings by code.
EnableAdditionalNuGetWarnings, and we'd set values such as NU1510;NU1511 etc.
This is very granular and as powerful as editoconfig is for configuring warnings, but the clear disadvantage is that if someone wants to have all warnings enabled, they'd need to keep specifying warnings as they come along.
An improvement on this would be allowing values such as all.
This is not as apparent as Idea 1, but it is more flexible.
Idea 3:
We have discuss the ideas of introduce linters, for things like NuGet.Config, NuGet/Home#13469. We could play with thins like "messages" that can be turned into warnings etc. With terminal logger in place however, the feasibility of such an approach is lesser.
Note that this is just an initial write-up and I'd be happy to write-up a full fledged proposal, but I wanted to get thoughts and opinions from folks about the direction before I go into all that detail.