.NET [SuppressMessage] attributes in shipping assemblies fxcop

Question

I wonder if people (meaning the company/developers) really care about having [SuppressMessage] attributes lying around in the shipping assemblies.

Creating separate configs in the Project files that include CODE_ANALYSIS in Release mode and then yanking it off in the final build seems kind of an avoidable overhead to me.

What'll be the best stratergy, if one does not want these to remain in the final assembly but still want to use them in code ? and Is there any advantages/disadvantages of storing them in FxCop Project files ?

[I'm coming from a VS2008 Pro+FxCop 1.36, rather than VS2008 Team System]

Answer 1

The SuppressMessage attribute will only be added to your code if the CODE_ANALYSIS preprocessor definition is present during a compile. You can verify this by looking at the definition of the attribute in Reflector.exe. By default this is not defined in Release so it won't affect production code.

Typically, I only run FxCop on DEBUG builds of my assembly where CODE_ANALYSIS is defined.

Answer 2

In the grand scheme of things, I don't think it really matters. Since this is an attribute (effectively meta-data), it doesn't impact code performance. That being said, do remember that the information in the attribute is available to anyone using a disassember like Reflector.

The problem with storing them in the FxCop project file is that you must then ensure that everyone uses the same project file and that the project file always travels with the project (it's checked in to source control, which means you must check it out each time you want to run FxCop).

If you don't want the SuppressMessage attributes in your production code you would need to only define the CODE_ANALYSIS symbol in the build you are running FxCop against. This does mean defining it either on your Debug configuration or adding additional configurations. The attributes will only be compiled in to the code when the symbol is defined.

From an automated/nightly build viewpoint, you can build using a configuration that has the symbol defined and then build the production release without the symbol or do two builds - one with the symbol defined, run FxCop to get your violations, and then another build without the symbol defined.

Answer 3

We have a ton scattered around production code, and we don't particularly care. It doesn't effect perf, and having some crufty looking attribute in a class often gives motivation to remove it if at all possible.