How can I mark a CA [SuppressMessage] as "blessed"?

Question

Try as I might to keep [SuppressMessage]s to a minimum in the codebase, new ones continue to get introduced. I would like some way to say in the code "I've reviewed this [SuppressMessage] and it is 'acceptable'".

One thought was to create my own My.CodeAnalysis.SuppressMessageAttribute class which inherits from System.Diagnostics.CodeAnalysis.SuppressMessageAttribute, but that class is sealed.

I'm sure I could cobble together something with a comment near the attribute and a post-processing step, but I'd like to stick to what is available "in the box" with Visual Studio 2010.

Answer 1

When you right-click on the CA warning in the errors list, one of the options given is Suppress Message(s) -> In Project Suppression File. When you select that, Visual Studio will add a line like the following to a GlobalSuppressions.cs file in your project:

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Naming", "CA1704:IdentifiersShouldBeSpelledCorrectly", MessageId = "Autofac")]

This keeps them grouped together and out of your code files. Is this what you are trying to get at?

Answer 2

Even if the attribute weren't sealed, a subclassing approach would not work since the code analysis engine screens for exact SuppressMessageAttribute instances. As current versions are written, the engine would completely ignore subclass instances.

Personally, I use the following approach for management of suppressions:

1. All "permanent" suppressions must have a Justification property that explains the reason for the suppression.
2. Where possible, permanent suppressions must be placed in the target code file. Otherwise, they must be placed at the top of the GlobalSuppressions file.
3. Temporary suppressions must all be placed below a "Temporary suppressions" header comment in the GlobalSuppressions file, and they should not be assigned a justification.
4. All permanent suppressions are subject to code review, in exactly the same manner as the code itself. I use difference detection to flag code for review, so I can see which suppressions have been added or changed just as easily as I can see which code has been modified.
5. Temporary suppressions must all be removed by a pre-defined phase of the project. After this point has passed, a rule that detects missing Justification properties is enabled.

If this sort of thing wouldn't work for you, another approach would be to use stand-alone FxCop to annotate your suppressed violations. Unfortunately, these annotations would reside outside your code base, but maybe that would suit you better if you want to prevent developers from "blessing" their own suppressions.