Настройка параметров анализа кода в TFSBuild.proj

Я пытаюсь установить / переопределить некоторые настройки в нашей тестовой установке TFS в отношении принудительного анализа кода и ассоциированных настроек во время процесса сборки (независимо от настройки sin файла проекта)

в настоящее время мы используем в нашей тестовой установке TFS:

  • Visual Studio 2012 Ultimate на наших компьютерах разработчиков и сервере сборки
  • есть TFS 2012 установлен на одном сервере (приложение и уровень данных)
  • имейте TFS 2012 служба сборки (контроллер и агент), установленная на другом сервере

мы можем скомпилировать примеры проектов .net 4.5 (библиотеки классов (DLL), веб-приложения и т. д.), Как ожидалось. Это связано исключительно с переопределением связанных параметров анализа кода (надеюсь).

Сценарий 1-в наших примерах приложений на наших компьютерах разработчиков при выборе параметров проекта (щелкните правой кнопкой мыши - > Свойства в обозревателе решений) перейдите на вкладку анализ кода, если я включу "Включить анализ кода при сборке" и выбрать набор правил из раскрывающегося списка выполняется как exepcted, поэтому он будет генерировать некоторые предупреждения. Это техническое добавляет <RunCodeAnalysis>false</RunCodeAnalysis> на *.файл csproj, если он открыт в блокноте. Если сборка выполняется для компиляции образца проекта / решения, анализ кода выполняется так, как ожидалось. Я не хочу делать это в каждом проекте, потому что разработчик может отключить его (Хотя я хочу иметь политики регистрации и / или частные / закрытые проверки, а также принудительно это все равно).

Сценарий 2 - я могу отключить флажок "Включить анализ кода при сборке" и принудительный анализ кода в нашем TFSBuild.файл proj (мы (будем) использовать upgradetemplate по умолчанию.xaml как наше определение процесса, потому что мы будем обновлять с TFS 2008 на нашей установке LIVE TFS), имея:

<RunCodeAnalysis>Always</RunCodeAnalysis>

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

проблема возникает при установке других параметров assosicated анализа кода. Например, какой набор правил по умолчанию применять / использовать или рассматривать предупреждения ЦС как ошибки. Некоторые из этих настроек можно установить либо в VS, либо во всех, отредактировав *.csproj в блокнот. Если я отредактирую *.csproj затем эти значения используются в сборке, как ожидалось (а также локально на машине разработчика). Это не идеально, поскольку я хочу сделать это централизованно в TFSBuild.proj без необходимости редактировать каждый файл проекта. Я считаю, что могу использовать такие настройки, как в моем TFSbuild.файл proj:

<PropertyGroup>
    <RunCodeAnalysis>Always</RunCodeAnalysis>
    <CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
    <CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
</PropertyGroup>

но они, похоже, не работают, или я ставлю их не в то место? Как исправить / использовать их правильно?

FYI я строю свои решения в TFSBuild.proj by:

<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">

  <Import Project="$(MSBuildExtensionsPath)MicrosoftVisualStudioTeamBuildMicrosoft.TeamFoundation.Build.targets" />
          <ItemGroup>
            <SolutionToBuild Include="/some folder/some solution.sln" />
            <ConfigurationToBuild Include="Debug|Any CPU">
               <FlavorToBuild>Debug</FlavorToBuild>
               <PlatformToBuild>Any CPU</PlatformToBuild>
             </ConfigurationToBuild>
          </ItemGroup>
</Project>

на сервере сборки я нашел ссылку на целевой файл для анализа кода на c:Program файлы (x86)MSBuildMicrosoftVisualStudiov11.0CodeAnalysis, но я не хочу изменять значение по умолчанию поведение на сервере сборки (хотя оно работает, когда я это делаю). Условие, например для CodeAnalysisTreatWarningsAsErrors должно оцениваться как false. Его как мои значения не читаются из TFSBuild.proj но от .файл csproj.

любые вопросы не стесняйтесь задавать и заранее спасибо

2 ответов


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

Я создал ItemGroup выходных DLL, FilesToAnalyze и подал его в FxCop способом, подобным:

<PropertyGroup>
      <FxCopErrorLinePattern>: error</FxCopErrorLinePattern>
      <FxCopCommand>"$(FxCopPath)" /gac /rule:"$(FxCopRules)" /ruleset:="$(FxCopRuleSet)"  @(FilesToAnalyze->'/file:"%(identity)"', ' ') /out:$(FullFxCopLog) /console | Find "$(FxCopErrorLinePattern)" > "$(FxCopLogFile)"</FxCopCommand>
</PropertyGroup>    

<Exec Command="$(FxCopCommand)"
      ContinueOnError="true">
  <Output TaskParameter="ExitCode" PropertyName="FxCopExitCode"/>
</Exec>

<ReadLinesFromFile File="$(FxCopLogFile)">
    <Output TaskParameter="Lines" ItemName="AllErrorLines"/>
</ReadLinesFromFile>

затем я мог бы определить количество ошибок в выходных данных с помощью задачи extensionpack:

<MSBuild.ExtensionPack.Framework.MsBuildHelper TaskAction="GetItemCount" InputItems1="@(AllErrorLines)">
    <Output TaskParameter="ItemCount" PropertyName="FxErrorCount"/>
</MSBuild.ExtensionPack.Framework.MsBuildHelper>

и создайте шаг неудачной сборки для каждой ошибки:

<BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Id="$(FxCopStep)"
        Status="Failed"
        Message="FxCop Failed: $(FxErrorCount) errors."/>

<BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
                BuildUri="$(BuildUri)"
                Status="Failed"
                Message="%(AllErrorLines.Identity)"/>

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


у меня было то, что я думаю, аналогичная проблема с круиз-контролем, не компилируемым с помощью CODE_ANALYSIS символ компиляции, даже если" включить анализ кода при построении (определяет константу CODE_ANALYSIS) " был зарегистрирован в VS.Net.

похоже, что это проверка или нет, CODE_ANALYSIS фактически не добавляется явно в список символов компиляции в csproj (даже если он появляется в текстовом поле "условные символы компиляции"), только это.

при компиляции через VS.Net, the CODE_ANALYSIS автоматически добавляется, но не при использовании MSBuild, который использует круиз-контроль.

Я в итоге изменил в VS.Net в "символы условной компиляции" из "CODE_ANALYSIS;MySymbol" в "MySymbol;CODE_ANALYSIS". Делать это принудительно CODE_ANALYSIS также появится в csproj.