Даже если атрибут не был запечатан, подход с использованием подклассов не будет работать, поскольку механизм анализа кода просматривает точные экземпляры SuppressMessageAttribute.По мере написания текущих версий механизм полностью игнорирует экземпляры подкласса.
Лично я использую следующий подход для управления подавлениями:
- Все "постоянные" подавления должны иметь обоснованиесвойство, которое объясняет причину подавления.
- Где возможно, постоянные подавления должны быть помещены в целевой файл кода.В противном случае они должны быть размещены в верхней части файла GlobalSuppressions.
- Все временные подавления должны быть помещены ниже комментария заголовка «Временные подавления» в файле GlobalSuppressions, и им не должно быть назначено обоснование.*
- Все постоянные подавления подлежат проверке кода, точно так же, как и сам код.Я использую обнаружение различий, чтобы пометить код для проверки, чтобы я мог видеть, какие подавления были добавлены или изменены, так же легко, как и какой код был изменен.
- Все временные подавления должны быть удалены предварительноопределенная фаза проекта.После того, как этот пункт пройден, правило, которое обнаруживает отсутствующие свойства Justification, становится активным.
Если подобные вещи не будут работать для вас, другой подход будет использовать автономный FxCop для аннотирования вашегоподавленные нарушения.К сожалению, эти аннотации будут находиться за пределами вашей кодовой базы, но, возможно, это подойдет вам лучше, если вы хотите, чтобы разработчики не «благословляли» свои собственные подавления.