Inevitable breaking changes because of code analysis and TreatWarningsAsErrors=true

[marco-eckstein]

Describe the bug

In my .csproj file, I have:

<TargetFramework>net8.0</TargetFramework>
<LangVersion>12</LangVersion>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<AnalysisLevel>8.0</AnalysisLevel>
<AnalysisMode>all</AnalysisMode>

The build is fine for SDK 8.0.1xx versions. For higher SDK versions (8.0.2xx, 8.0.3xx, 8.0.4xx, 9.0.100) the build breaks due to new code analysis warnings that are treated as errors.

The only way of solving this issue is to fix the SDK version range via the global.json file. This introduces friction for developers and devops who are forced to maintain old SDK versions side-by-side with new SDK versions (for other projects) on development and build machines.

New SDK versions should not enable new code analysis rules by default, or at least there should be a switch to opt out of this practice.

For people with TreatWarningsAsErrors enabled, the current update policy is as bad as it would be to make backwards-incompatible compiler changes within the same major version.

[marco-eckstein]

After further investigation, I see my assumption that new rules have been introduced within the same SDK major version was wrong in some cases. It seems that the analyzer changed its behavior regarding existing rules, thus just finding more violations. However, I did find one rule that was added somewhere between 8.0.100 and 8.0.404: IDE0320

[marcpopMSFT]

@jaredpar @arunchndr to review the analyzer warnings as they likely come from their teams. Tools are not supposed to add new warnings in feature band releases when possible and instead tie them to the major release. So I would expect new warnings in 9.0.100, just not in 2/3/4 (with some exceptions)

[arunchndr]

@JoeRobich would you check if this is related to the AnalysisLevel enablement?

[JoeRobich]

The AnalysisLevel enablement of code style warnings required level 9.0 or higher. The example .csproj from the issue description uses 8.0, so I would not think it is the problem here.

It seems that the analyzer changed its behavior regarding existing rules

It is possible that bug fixes could cause false negatives to start being reported properly.

However, I did find one rule that was added somewhere between 8.0.100 and 8.0.404: IDE0320

IDE0320 was added for 17.11p1 but was given a default severity of suggestion. New code style analyzers are only given suggestion or silent severity.

@marco-eckstein Other than IDE0320, are there particular diagnostics ids that you are seeing be reported differently between 8.0.1xx and 8.0.4xx?