TreatWarningsAsErrors doesn't work for MSB3277

[skolima]

Due to upgrades made in #608 , the dreaded warning MSB3277 Found conflicts between different versions of the same dependent assembly that could not be resolved. is now (somewhat) easily actionable from the Visual Studio. However, in times of CI/CD and https://dependabot.com/ , I don't want to have to wait for a deployment to fail in order to notice that MSBuild already knew at build time my project won't start.

However, no matter how strict the MSBuild settings are, this is always emitted as warning, not error.

Please make the MSB3277 respect TreatWarningsAsErrors and related flags.

Related (6 year old, still valid) StackOverflow thread https://stackoverflow.com/q/23662639/3205

[rainersigwald]

You can use the generic mechanism MSBuildTreatWarningsAsErrors or < MSBuildWarningsAsErrors>MSB3277</MSBuildWarningsAsErrors> (introduced in #1928) to accomplish this. We're considering treating TreatWarningsAsErrors in the same way (#4421). It wasn't done that way initially out of concern about changing the behavior of existing projects--but it is a completely reasonable expectation!

("Ok, Rainer, but those aren't documented!" you might say. To which I preemptively reply: you're right! https://github.com/MicrosoftDocs/visualstudio-docs/issues/4660)

[rainersigwald]

Duplicate of #4421

[wouterroos]

Hi,

Is there also an equivalent for WarningsNotAsErrors? Ideally, you'd want to threat every warning as an error (especially in a CI-scenario) and be able to whitelist specific warnings when there is a genuine reason to.

[rainersigwald]

@wouterroos that's #3062.

[wouterroos]

@rainersigwald Thanks for your response. How would this work when setting properties in *.csproj files? I have the following scenario: We have set <MSBuildTreatWarningsAsErrors>true</MSBuildTreatWarningsAsErrors> in our Directory.Build.props file since we'd like to fail our ci build on any unexpected warnings. However, due to this issue in aspnetcore we would like to whitelist MSB3539 for specific projects so that the build won't fail and it will show as a warning. I tried various combinations of seemingly related properties I found at this page but unfortunately I haven't been able to figure out a way to make this work. Any suggestions?

[rainersigwald]

@wouterroos There's no way to make it appear as a warning today. You can either suppress it entirely or turn off warnings-as-errors in those projects. The issue I linked would allow you to get the behavior you want but isn't implemented.

[julealgon]

@rainersigwald just to make sure I'm understanding this correctly. I believe my case is similar to @wouterroos ' in that "I want to handle everything as an error by default, with the exception of specific warnings that should be whitelisted".

We were previously using he TreatWarningsAsErrors flag in combination with WarningsNotAsErrors to exclude deprecation warnings 612 and 618. This was working fine, but I noticed MSB3277 was being raised as a warning still, which was undesirable.

I then found out about MSBuildTreatWarningsAsErrors, however when I enabled it, suddenly the deprecation warnings, which were showing as warnings previously due to WarningsNotAsErrors, started appearing as errors in the build.

Is WarningsNotAsErrors just flat out ignored when MSBuildTreatWarningsAsErrors? If so, why is that the case?

The only way I got it to work was by not setting MSBuildTreatWarningsAsErrors, and instead explicitly adding the MSB3277 warning in the MSBuildWarningsAsErrors property. However this is far from ideal, since I'd then need to know each and every warning possible to protect my build, i.e. move from a whitelist solution into a blacklist one.

Are there any short-term plans to fix all this confusion and adopt a unified approach that allows both whitelist and blacklist strategies for warnings?

Apologies if this was already answered, but this is all very confusing and unintuitive to me. The very fact that we have separate TreatWarningsAsErrors and MSBuildTreatWarningsAsErrors flags is puzzling and smells of poor design in my view.

I'm hesitant of relying on MSBuildWarningsAsErrors since that would force several hardcodes I don't want to maintain in the project.

EDIT:

Also, I found this post from you in another thread, suggesting that TreatWarningsAsErrors should work in my scenario (at least that's what I interpreted), however it does not. I'm using VS 16.11.5 which from what I understand has a newer version of MSBuild than 16.9:

• Add a "treat warnings as errors" option #68 (comment)

[Forgind]

@julealgon, the compiler and MSBuild sometimes handle flags like TreatWarningsAsErrors the same way but sometimes don't. In this case, MSBuild didn't recognize WarningsNotAsErrors as a thing in all cases. The compiler was upgrading warnings other than 612 and 618 to errors, and MSBuild wasn't changing any warnings to errors. When you added MSBuildTreatWarningsAsErrors, it was taking all warnings (given to it by the compiler as well as other sources) and converting them to errors—and since WarningsNotAsErrors was only a compiler thing, there were no exceptions.

One difficulty from a design perspective is that MSBuild can run without any specific compiler and vice versa, hence having disjoint systems.

In any case, I merged the feature for specifying just a few warnings to not be errors yesterday, so it should hopefully come out in 17.2. Hope that helps!