"Treat all warnings as errors except..." in Visual Studio

In Visual Studio, I can select the "Treat warnings as errors" option to prevent my code from compiling if there are any warnings. Our team uses this option, but there are two warnings we would like to keep as warnings.

There is an option to suppress warnings, but we DO want them to show up as warnings, so that won't work.

It appears that the only way to get the behavior we want is to enter a list of every C# warning number into the "Specific warnings" text box, except for the two we want treated as warnings.

Besides the maintenance headache, the biggest disadvantage to this approach is that a few warnings do not have numbers, so they can't be referenced explicitly. For example, "Could not resolve this reference. Could not locate assembly 'Data....'"

Does anyone know of a better way to do this?

---

Clarifying for those who don't see immediately why this is useful. Think about how most warnings work. They tell you something is a little off in the code you just wrote. It takes about 10 seconds to fix them, and that keeps the code base cleaner.

The "Obsolete" warning is very different from this. Sometimes fixing it means just consuming a new method signature. But if an entire class is obsolete, and you have usage of it scattered through hundreds of thousands of lines of code, it could take weeks or more to fix. You don't want the build to be broken for that long, but you definitely DO want to see a warning about it. This isn't just a hypothetical case--this has happened to us.

Literal "#warning" warnings are also unique. I often want to check it in, but I don't want to break the build.

You can add a WarningsNotAsErrors-tag in the project file.

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

Note: 612 and 618 are both warnings about Obsolete, don't know the difference but the project i'm working on is reporting Obsolete with warning 618.

/warnaserror /warnaserror-:618

or more specifically, in your case:

/warnaserror /warnaserror-:612,1030,1701,1702

this should treat all warnings as errors except for the ones in your comma separated list

In Visual Studio 2022 we have a new Project Properties UI which includes an editor for this.

Under Build | Errors and Warnings if you set Treat warnings as errors to All, then another property appears which allows you to exempt specific warnings from being treated as errors:

This will add the following property to your project:

<WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>

Why do you want to keep seeing warnings that you are not treating as errors? I am confused about why this is desirable - either you fix them or you don't.

Would two different build/solution files work - or a script to copy one and then so modify the warnings/warning level be suitable. It seems that perhaps you want some executions of the compiler to squawk, but others you want to keep going.

So different compiler switches seems like a good way to go. You could do this with different targets - one labeled debug or release and the others labeled suitably about the warnings.

I'm using treat warnings as errors.

In a rare cases, when some acceptable warning shows up (i.e. referencing obsolete member, or missing documentation on XML serialization classes), then it has to be explicitly suppressed with #pragma disable (and optionally reason for not having a clean code could be provided as a comment along).

Presence of this directive also allows to find out, who accepted this warning violation (by "blame" action of version control) in case there are some questions.

Why not simply have a rule saying "Whoever checks in code with any warning inside it other than 612, 1030, 1701 or 1702 in it must go to the whiteboard and write a hundred times 'I will not check in code with disallowed warnings again.'"

pragma warning (C# Reference)

pragma warning may be used to enable or disable certain warnings.

<http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx>

It seems to me the root problem is really a combination of your treating warnings as errors, when they are clearly not, and your apparent policy of permitting check-ins which violate this. As you say, you want to be able to continue working despite a warning. You've only mentioned a few warnings you want to be able to ignore, but what if someone else on the team caused any other type of warning, which would take you equally long to fix? Wouldn't you want to be able to ignore that as well?

The logical solution would be to either 1) Disallow checkins if the code doesn't compile (which means those who created the warnings will have to fix them, since in effect, they broke the build), or 2) treat warnings as warnings. Create two build configurations, one which treats warnings as errors, which can be run regularly to ensure that the code is warning-free, and another, which only treats them as warnings, and allows you to work even if someone else introduced a warning.