Атрибуты .NET [SuppressMessage] в доставочных сборках fxcop - PullRequest
7 голосов
/ 03 декабря 2008

Интересно, действительно ли люди (имея в виду компанию / разработчики) действительно заботятся о том, чтобы атрибуты [SuppressMessage] валялись в отгрузочных сборках.

Создание отдельных конфигов в файлах проекта, которые включают CODE_ANALYSIS в режиме выпуска, а затем их отключение в окончательной сборке, кажется мне излишним расходом.

Какая будет лучшая стратегия, если кто-то не хочет, чтобы они оставались в окончательной сборке, но все же хотел использовать их в коде? и есть ли какие-либо преимущества / недостатки их хранения в файлах проекта FxCop?

[Я использую VS2008 Pro + FxCop 1.36, а не VS2008 Team System]

Ответы [ 3 ]

7 голосов
/ 03 декабря 2008

Атрибут SuppressMessage будет добавлен в ваш код, только если во время компиляции присутствует определение препроцессора CODE_ANALYSIS. Вы можете убедиться в этом, посмотрев на определение атрибута в Reflector.exe. По умолчанию это не определено в Release, поэтому это не повлияет на производственный код.

Обычно я запускаю FxCop только в сборках DEBUG моей сборки, где определен CODE_ANALYSIS.

2 голосов
/ 03 декабря 2008

В общем, я не думаю, что это действительно имеет значение. Поскольку это атрибут (фактически метаданные), он не влияет на производительность кода. При этом помните, что информация в атрибуте доступна любому, кто использует дизассемблер, например, Reflector.

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

Если вам не нужны атрибуты SuppressMessage в вашем производственном коде, вам нужно будет определить только символ CODE_ANALYSIS в сборке, с которой вы запускаете FxCop. Это означает, что вы можете определить его в своей конфигурации Debug или добавить дополнительные конфигурации. Атрибуты будут скомпилированы в код только после определения символа.

С точки зрения автоматической / ночной сборки вы можете построить с использованием конфигурации, для которой определен символ, а затем собрать производственную версию без символа или выполнить две сборки - одну с определенным символом, запустить FxCop, чтобы получить ваши нарушения, и затем другая сборка без определенного символа.

1 голос
/ 03 декабря 2008

У нас есть тонна разбросанных по производственному коду, и нас это не особо волнует. Это не влияет на производительность, и наличие в классе какого-то грубого атрибута часто дает мотивацию удалить его, если это вообще возможно.

...