Background

Currently the rules have fixed defaults - overridable by customer in editorconfig.
The idea of 'WarningWaves' is to slowly enable and increase severity of specific rules - to allow users to onboard with lower noise and over time get more strictness.
We should not increase number of rules and their severity simply with new versions of MSBuild - that would break VS upgrading scenarios. Customers with unchanged projects/solutions should get identical reports regardless of MSBuild version they are using,
however they should get more rules and more strictness based on some explicit gesture of theirs. Increasing the version in TFM feels like a good candidate. SdkAnalysisLevel was designed for this specifically.

Goal

• Study the design doc - Add a design for SdkAnalysisLevel designs#308 and propose the solution.
• Built-in analyzers are priority in this, as acquired analyzers [nuget/project/binary] are imported already based on an explicit gesture.
• But if we design/code this so that type of analyzer (built-in vs acquired) doesn't matter - we can expose the functionality to both types.

Gotchas

• For Visual Studio (so FullFW MSBuild) we very likely do not want to introduce breaking behavior without code change on user side
• Different behavior (and even build succeeding vs failing) on commandline vs in VS might not be perceived good
• The TFM is not know untill certain point in evaluation - so we might need buffer some potential input into analyzers or vice versa send all input unrestricted, but buffer output untill we are sure what the right configuration should be.
• Similarly with $SdkAnalysisLevel as it is an MSBuild property. This is problematic - as until evaluation starts we would not know whether the enalyzer will be enabled or not - and some analyzers will need to request some extra data

Related

• Add a design for SdkAnalysisLevel designs#308
• .NET SDK Breaking Changes proposal doc
• SdkAnalysisLevel proposal doc