Analyzers prototyping - Opting in/out

[JanKrivanek]

Context

#9627

Users should be able to turn off or on the anlyzers run globally (in order to speedup or troubleshoot problematci runs), regardless of what will be the default behavior. At the same time MSBuild team should have a default behavior (likely it's opt-in-only in initial versions, then opt-out-only later on), which might as well be influenced by concrete run scenario (sdk run, msbuild.exe run, API invoking, binlog replay, etc.)

As part of this item one should propose and find consensus for opting in and out of anlyzing behavior. An inspiration might be a TerminalLogger opt -in/-out behavior (but hopefully we should start more simple). Sample initial behavior might be as follows:

• Off by default in all scenarios
• Env var for overriding the default behavior
• Cmd switch for overriding default or env

Reference

• TerminalLogger opt-in/out code: https://github.com/dotnet/msbuild/blob/e71eb7a1fc535b438007286c840d7cecc139d13b/src/MSBuild/XMake.cs#L2715-L2910

FYI @baronfel to express opinions on desired behavior

[baronfel]

Roslyn analyzers have two opt-in modes:

• for NuGet-delivered Analyzers, the act of adding the PackageReference adds the Analyzer as well
• for .NET SDK-delivered Analyzers, there are boolean MSBuild properties that control if the analyzer is used

in both cases, as long as there are any analyzers requested, analysis occurs. This model is ideally what I would like us to use, as users are already trained in this mode of use.

[JanKrivanek]

@baronfel - can you elaborate more on the boolean MSBuild properties for the built-in analyzers?

Inline with Roslyn - Analyzers have default state (enabled/disabled) hardcoded, plus it is overridable via .editorconfig. Is the msbuild prop an override of both of those (so that one can tune the behavior in different environments - CI/dev - just via commandline, without need to touch any code)?