2011-01-18 2 views
10

Мы используем глобальные подавления FxCop для подавления нарушений правил, обнаруженных в старом коде. По старому коду я имею в виду код, который был написан иногда за несколько лет до того, как мы включили анализ кода. Мы исправляем нарушения в новом коде. Мы не можем исправлять нарушения в старом коде одновременно, поэтому мы используем подавления.Есть ли способ идентифицировать неиспользуемые или устаревшие подавления сообщений FxCop?

Со временем наши глобальные файлы подавления стали раздутыми. Часто, когда подпись изменилась по старому методу, предыдущее подавление становится недействительным, поскольку оно больше не совпадает с кодом. Мы создали новые подавления, чтобы игнорировать старые нарушения, но часто старые атрибуты SuppressMessage были оставлены позади.

Кто-нибудь знает, как идентифицировать эти объявления SupressMessage, которые не совпадают с кодом? В этом отношении кто-нибудь знает, как идентифицировать атрибуты SuppressMessage, которые являются недействительными, потому что нет нарушения для подавления?

Я думаю, что может быть сообщение о компиляторе или FxCopCmd или сообщение журнала, которое могло бы идентифицировать неиспользуемые запреты. Если нет, кто-нибудь знает о сценарии или расширении VS, которое это делает?

Спасибо.

+0

Надеюсь, вы планируете в конечном итоге удалить все эти подавления. Я нахожу, что они загромождают код, если его используют слишком много. – Bernard

+0

@Bernard - Глобальные подавления не входят в ваши файлы классов, поэтому вы не увидите их, если не найдете их. Боль - это когда вы пытаетесь найти тот, который хотите удалить или изменить. – Pedro

+0

@Pedro: Вы правы. Но вы также можете подавлять предупреждения на уровне метода, которые я бы не рекомендовал делать. – Bernard

ответ

2

Для этого можно использовать автономное приложение FxCop. Добавьте столбец «Виден последний прогон» на вкладку «Исключенные источники». После анализа этот столбец покажет ложное значение для любых подавлений в источнике, для которых соответствующее нарушение не было обнаружено во время анализа. Чтобы максимально повысить надежность результатов, вы должны убедиться, что используете тот же набор сборщиков правил для анализа, который вы используете при выполнении анализа из Visual Studio.

BTW, если вы хотите, чтобы у вас была возможность разбить вашу сборку, когда найдены «устаревшие» подавления, вы можете рассмотреть возможность голосования по адресу https://connect.microsoft.com/visualstudio/feedback/details/277253/add-mechanism-for-detecting-unnecessary-suppressmessageattribute-instances.

+0

Спасибо, я сейчас попробую. –

+1

Ссылка кажется сломанной, и я не смог ее найти. Не могли бы вы обновить свой пост? – julealgon

Смежные вопросы