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


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

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

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

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

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

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

<RunCodeAnalysis>Always</RunCodeAnalysis>

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

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

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

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

К вашему сведению, я строю свои решения в 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 должно быть получение оценки как ложное. Это похоже на то, что мои значения не читаются из TFSBuild.прой но находятся от своих .файл csproj.

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

2 7

2 ответа:

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

Я создал ItemGroup выходных библиотек DLL, Filestoanalize, и передал его в 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.

Похоже, что независимо от того, является ли это check или нет, CODE_ANALYSIS на самом деле явно не добавляется в список символов компиляции в csproj (даже если он появляется в текстовом поле "условные символы компиляции"), добавляется только <RunCodeAnalysis>true</RunCodeAnalysis>.

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

В конце концов я изменился в VS.Net условные символы компиляции от "CODE_ANALYSIS; MySymbol" до "MySymbol; CODE_ANALYSIS". Это заставило CODE_ANALYSIS также появиться в csproj.