Как отказать в сборке TFS на основе предупреждения FXCop - PullRequest
Новая
       17

Как отказать в сборке TFS на основе предупреждения FXCop

5 голосов
/ 24 августа 2010

В настоящее время мы используем TFS 2008 для контроля версий и непрерывной интеграции.

Мы используем FXCop для проверки производительности и предупреждений безопасности. Архитектор или старший разработчик запускает FX Cop в конце спринта или перед доставкой.

Мы бы хотели, чтобы это работало как часть CI и не давало сборки, если есть предупреждение, каков наилучший способ сделать это?

Ответы [ 3 ]

6 голосов
/ 24 августа 2010

Вы можете взглянуть на функции анализа кода в Visual Studio , которая поддерживается для использования в среде непрерывной интеграции.

5 голосов
/ 22 декабря 2010

Я работал над чем-то похожим. Хотя этот вопрос немного устарел, я надеюсь, он вам поможет.

Я начал как обычно - с создания события после сборки, которое вызывает FxCopCmd.

В моем случае мне потребовалось лишь небольшое подмножество кода, некоторые встроенные правила, а также некоторые пользовательские правила (в .dll)

Я использовал для этого файл проекта .fxcop - все настраивал так, как я хотел через графический интерфейс, а затем указывал FxCopCmd на файл проекта в событии после сборки.

По большей части это сработало замечательно, но нарушение правил выглядело только как предупреждение. Опция «Обрабатывать предупреждения как ошибки», похоже, не относится к этому, поэтому мне пришлось придумать другое решение.

То, что в конечном итоге мне больше всего помогло, было основано на сообщении в блоге, на которое я наткнулся.

Я изменил файл проекта, добавив в него два новых события.

У меня есть несколько дополнительных параметров и вещей для FxCop, но суть этого: 

   1: <PropertyGroup>
   2:   <FxCopResults>$(ProjectDir)obj\$(Configuration)\FxCopResults.xml</FxCopResults>
   3:   <PostBuildEvent>"%25ProgramFiles%25\Microsoft FxCop 10.0\FxCopCmd.exe" /file:"$(TargetPath)" /console /out:"$(ProjectDir)obj\$(ConfigurationName)\FxCopResults.xml"</PostBuildEvent>
   4: </PropertyGroup>
   5: <Target Name="BeforeBuild">
   6:   <Delete Files="$(FxCopResults)" ContinueOnError="true" />
   7: </Target>
   8: <Target Name="AfterBuild">
   9:   <Error Text="One or more FxCop warnings occurred." Condition="Exists('$(FxCopResults)')" />
  10: </Target>

Общий поток такой:

  1. (ПРОЦЕСС СТРОИТЕЛЬСТВА ТРИГГЕРЕН)
  2. Перед началом сборки предыдущие результаты FxCop (если они существуют) удаляются.
  3. Событие перед сборкой запускается
  4. (НАЧАЛО СТРОИТЬ)
  5. Событие после сборки запускается (запускается FxCopCmd)
  6. После завершения пост-сборки, если есть результаты FxCop, возникает ошибка.
  7. (ПРОЦЕСС СТРОИТЕЛЬСТВА ЗАВЕРШЕН)

Теперь, если анализ FxCop сгенерировал, например, 4 нарушения правил, ваша сборка выдаст 4 предупреждения и 1 ошибку.

Надеюсь, это поможет.

3 голосов
/ 24 августа 2010

Предполагая, что вы работаете с MSBuild и обычными проектами / решениями, вы можете настроить FXCop для работы как части каждой сборки (как клиента, так и сервера). В диалоговом окне свойств вашего проекта откройте вкладку «Анализ кода». Обратите внимание, что это можно установить отдельно для отладочной и выпускной сборок, так что вы можете просто установить их на ошибки для сборок выпуска, если это облегчит жизнь вашим разработчикам.

Эти настройки FXCop позволяют определить, что нарушения появляются как ошибки, а не как предупреждения в сборке. Вы также можете включить политику TFS, которая требует, чтобы анализ кода выполнялся с определенным набором правил, прежде чем проверка будет действительной - это сэкономит вам некоторые красные сборки, заставляя разработчиков исправлять нарушения перед проверкой.

Я рекомендую включить все эти вещи - если вы стремитесь к этому уровню качества (что не является плохой идеей), хорошо делать столько, сколько вы можете предварительно проверить.

...