Как можно реализовать FxCop / статический анализ на существующей базе кода

Для начала широко используйте атрибут [SuppressMessage]. По крайней мере, в самом начале. После того, как вы получите счетчик до 0 с помощью атрибута, вы затем поставите правило, что новые проверки не могут вводить FxCop нарушений.

В Visual Studio 2008 есть хорошая функция анализа кода, которая позволяет гарантировать, что анализ кода выполняется на каждой сборке, и вы можете рассматривать предупреждения как ошибки. Это может немного замедлить процесс, поэтому я рекомендую настроить сервер непрерывной интеграции (например, CruiseControl.NET) и заставить его выполнять анализ кода при каждой проверке.

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

Способ отслеживать, какие из них вы действительно хотите сохранить, - это всегда добавлять значение оправдания к тем, которые вы действительно хотите подавить.

Перепишите свой код в проходящем стиле!

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

Так что просто укусите пулю, выпейте много кофеина и просто пройдите через это за пару дней!

NDepend выглядит так , что он может сделать то, что вы ищете, но я не уверен, что он может быть интегрирован в автоматизированную сборку CruiseControl.Net, и не сможет выполнить сборку, если код не соответствует требованиям (что я и хотел бы сделать).

Есть еще какие-нибудь идеи?

Альтернативой FxCop может быть использование инструмента NDepend . Этот инструмент позволяет писать правила кода для C# LINQ запросов (то, что мы называем CQLinq ). Отказ от ответственности: я являюсь одним из разработчиков инструмента

По умолчанию предлагается более 200 правил кода . Настройка существующих правил или создание собственных правил очень просто благодаря хорошо известному синтаксису C# LINQ.

Чтобы уменьшить количество ложных срабатываний, CQLinq предлагает уникальные возможности для определения того, что такое набор JustMyCode , с помощью специальных запросов кода, префиксированных notmycode . Более подробное описание этой функции можно найти здесь . Вот например два запроса notmycode по умолчанию:

• Отбросить созданные и конструкторские методы из JustMyCode
• Отбросить сгенерированные типы из JustMyCode

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

warnif count > 0 
from m in Methods
where m.CyclomaticComplexity > 20 &&
      m.WasAdded() || m.CodeWasChanged()
select new { m, m.CyclomaticComplexity }

Наконец, обратите внимание, что с помощью NDepend правила кода можно проверить в реальном времени в Visual Studio и во время процесса сборки в созданном отчете HTML+javascript .