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]
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.