#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 командная строка переключается в ваших сборках, поэтому ваш существующий подход, по-видимому, должен продолжать работать (возможно, после нескольких незначительных изменений).
Тем не менее, я предполагаю, что, вероятно, есть гораздо более простой способ добиться желаемого. Однако я не уверен, что полностью понимаю вашу конечную цель, поскольку ваш вопрос гораздо больше фокусируется на адаптации вашего существующего подхода. Если вам нужна помощь в попытке найти подход, который хорошо сочетается с возможностями нового инструмента, не могли бы вы предоставить более подробную информацию о том, что именно вы пытаетесь выполнить?