It’s not documented very well, but the C# compiler actually has 4 levels of warnings. I like to think of them this way:
- Level 1 – These warnings are cases the compiler is 99.9% sure you did something wrong, but the code is syntactically and semantically legal.
- Level 4 – These warnings are cases where the naive user probably did something unintended, and we want to make sure they’re aware of it.
- Level 2 and 3 are just somewhere in between.
This seems like a pretty reasonable set, although I’ve often wondered if 4 levels is the right number, maybe 3 or 2 would be better. Anyway, often times we get requests from the ASP.NET team to raise or lowere the level of certain warnings. Now the whole point of a warning is that it points out a possible problem with the code. As such the compiler team has always mandated that we will feel free to add new warnings where appropriate, so those people who build with /warnaserror are just asking to be broken when they upgrade (there’s a better way to do this and I’ll get to it later). Now back to ASP.NET, as anybody who has used it already knows, ASP.NET does not have a way of reporting warnings. They don’t go to a log or anything useful like that. Instead they build with /warnaserror turned on and the warning level set to 1. So all of our level 1 warnings become errors and break people’s web sites. Anybody see the problem here?
As promisied, here’s the right way to use /warnaserror: on your developer machines, before submitting changes. Then on your offical builds turn it off. Keep a warning log and send it to the developers, but don’t break your build because of a warning. I don’t know about your organization, but here a build break is painful!