Управление наборами правил CodeAnalysis для многих проектов в VS2010 (в основном подавления)

#visual-studio-2010 #code-analysis #suppress

#visual-studio-2010 #анализ кода #подавить

Вопрос:

Для работы с VS2005 и VS2008 мы определили наши текущие правила ca в списке sharepoint.

В списке есть столбец, в котором все исключенные сборки перечислены с разделением на полуколоны.

Пользовательская задача сборки прочитала список sharepoint и отвечала за исключение указанного правила в файле проекта с помощью «-!CA …» при командной сборке.

Теперь мы планируем перенести наши проекты на VS 2010, и новый набор правил анализа кода создает некоторые проблемы.

Первая идея заключалась в

  • создайте файл набора правил из sharepoint
  • добавьте GlobalSupressions.cs в качестве элемента решения и добавьте файл в каждый проект в виде связанного файла
  • создайте запись SupressMessage в GlobalSupressions.cs с целевым пространством имен и исключить

Я протестировал его с помощью небольшого решения с одним проектом. Похоже, что целевое пространство имен не работает.

Я искал в stackoverflow и Интернете, и основным ответом было то, что подавления с целевым пространством имен не работают.

Основное приложение содержит более 250 проектов.

Мне кажется, что единственный рабочий способ — создать n пользовательских наборов правил для разных проектов, в которых исключенные правила отключены.

Я не хочу проходить через полное приложение и повторно подавлять все правила в коде.

Как вы работаете с новыми наборами правил в такой ситуации?

Есть идеи, как я могу работать с новыми наборами правил простым и удобным способом? Список sharepoint является ведущей частью для определения правил анализа кода.

Редактировать 1

В предыдущих проектах мы управляли нашим определением набора правил анализа кода в списке sharepoint. В списке отображаются все правила ca в виде списка

  • номер ca
  • активировано
  • обрабатывается как ошибка
  • исключение (содержит имя участника проекта, например ‘Test’ или полное имя проекта / сборки)

Из списка создается набор правил, где

  • активировано handleAsError = правило включено
  • !активировано = отключить правило
  • активировано !handleAsError = предупреждение

Если столбец исключения имеет значение, например, ‘Test’, то во всех тестовых проектах правило должно быть отключено.

Ответ №1:

Ничто не заставляет вас переходить к новому файловому подходу .ruleset в VS2010. При желании вы можете продолжать использовать файлы проекта .fxcop или fxcopcmd.exe командная строка переключается в ваших сборках, поэтому ваш существующий подход, по-видимому, должен продолжать работать (возможно, после нескольких незначительных изменений).

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