Why does VS 2019 keep overriding my warnings setting?

Question

Kinda stumped on this one. I'm using a library from GitHub and it's throwing tons of warnings, so I went into the project's build settings, chose 'All Configurations' and chose 0 for the warning level under 'Errors and Warnings'. This added the following to the project file:

<WarningLevel>0</WarningLevel>

Rebuilding and all the warnings went away.

Then on the next build, they came right back! Huh?

Went back into the UI and saw it was set back to 5! I checked the project file and it was still at 0 as expected.

To test, I changed the level 2 in the UI, and as expected, the project file updated to this instantly:

<WarningLevel>2</WarningLevel>

But then, a few seconds later, the UI again snapped back to 5! WTF?!?!

I looked around to see if there was any global overrides but didn't find anything, although I'm not really sure what I'm looking for.

Anyone know what's going on? It's really @$#!@ annoying!

Here's my fork of the project if anyone else wants to take a look:

https://github.com/MarqueIV/WpfExtendedToolkit
(Forked from here: https://github.com/dotnetprojects/WpfExtendedToolkit)

Update

I checked out the project on a completely separate Win10 install where I also installed VS 2019 Community for the first time, and the same thing happened... it keeps 'resetting' the warning level, so it's something somewhere in the project itself I would think.

Answer 1

Ok, this isn't an 'answer' per se, but here's a workaround, at least for now to shut up the warnings.

In addition to WarningLevel, you have to also set the AnalysisLevel and RunAnalyzersDuringBuild by adding the following to your project.

<WarningLevel>0</WarningLevel>
<AnalysisLevel>none</AnalysisLevel>
<RunAnalyzersDuringBuild>false</RunAnalyzersDuringBuild>

That stops the warnings.

Still, there shouldn't be a case where something overrides WarningLevel which is why I'm posting this, but not marking it as the accepted answer. It isn't. It's a temporary, 'blunt-hammer' fix until they restore the behavior to the pre-.NET 5.0 way of it working. Let's hope that was an oversight and not an intentional change.