Ustawienia analizy kodu w TFSBuild.proj

Question

Próbuję ustawić/przesłonić niektóre ustawienia w naszej instalacji TEST TFS w odniesieniu do wymuszania analizy kodu i ustawień assosicated podczas procesu budowania (niezależnie od ustawienia pliku projektu)

obecnie stosujemy w naszej instalacji TEST TFS:

• Visual Studio 2012 Ostateczny na naszych maszynach deweloper i zbudować serwer
• Czy TFS 2012 zainstalowany na jednym serwerze (warstwa aplikacji i danych)
• Zbuduj usługę TFS 2012 (kontroler i agent) zainstalowany na innym serwerze

Możemy skompilować przykładowe projekty .net 4.5 (biblioteki klas (DLL), aplikacje internetowe itp.) Zgodnie z oczekiwaniami. Ma to wyłącznie związek z nadpisaniem ustawień analizy kodu (miejmy nadzieję).

Scenariusz 1 - W naszych przykładowych aplikacjach na naszych komputerach programistycznych po wybraniu ustawień projektu (prawy przycisk myszy -> właściwości w eksploratorze rozwiązań) przejdź do karty Analiza kodu, jeśli włączę opcję "Włącz analizę kodu przy kompilacji" i wybierz zestaw reguł z rozwijanego menu, który działa jako zewnętrzny, dlatego wygeneruje kilka ostrzeżeń. To techniczne dodaje <RunCodeAnalysis>false</RunCodeAnalysis> do pliku * .csproj, jeśli jest otwarty w notatniku. Jeśli kompilacja jest wykonywana w celu kompilacji przykładowego projektu/rozwiązania, wówczas analiza kodu jest przeprowadzana zgodnie z oczekiwaniami. NIE chcę tego robić w każdym projekcie, ponieważ programista może go wyłączyć (chociaż staram się mieć zasady check-in i/lub prywatne/kontrolowane checkiny, aby to wymusić).

Scenariusz 2 - Mogę wyłączyć pole wyboru "Włącz analizę kodu podczas kompilacji" i wymuś analizę kodu w pliku TFSBuild.proj (my (użyjemy) użyjemy domyślnej aktualizacji standardu.xaml jako naszej definicji procesu, ponieważ będziemy aktualizować z TFS 2008 na naszej LIVE instalacji TFS) poprzez:

<RunCodeAnalysis>Always</RunCodeAnalysis>

to działa i to w jaki sposób będziemy zmuszać (lekcje nadal się nauczyć :-)) Code Analysis na naszej buduje.

Problem pojawia się podczas ustawiania innych ustawień analizy kodu. Na przykład, które domyślne zestawy reguł mają stosować/używać lub traktować ostrzeżenia CA jako błędy. Niektóre z tych ustawień można ustawić w VS lub wszystkie z nich, edytując * .csproj w notatniku. Jeśli edytuję plik * .csproj, te wartości są używane w kompilacji zgodnie z oczekiwaniami (a także lokalnie na komputerze programisty). To nie jest idealne, ponieważ chcę to zrobić centralnie w TFSBuild.proj bez konieczności edycji każdego pliku projektu. Wierzę, że mogę korzystać z takich ustawień, jak w moim pliku TFSbuild.proj:

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

Ale nie wydaje się, aby pracować lub kładę je w niewłaściwym miejscu? Jak naprawić/użyć ich poprawnie?

FYI budować moje rozwiązania TFSBuild.proj przez:

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

    <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.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> 

Na serwerze kompilacji znalazłem odniesienie do pliku docelowego dla kodu Analiza w katalogu C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \ CodeAnalysis, ale nie chcę zmieniać domyślnego zachowania na serwerze kompilacji (chociaż działa, gdy robię). Warunek na przykład dla CodeAnalysisTreatWarningsAsErrors musi zostać oceniony jako fałszywy. To jak moje wartości nie są czytane z TFSBuild.proj, ale są z pliku .csproj.

Wszelkie pytania prosimy pytać i dzięki z góry

Answer 1

Pamiętam, że podobny problem - ale nie mają czasu, aby go dokładnie przebadać, pracowałem wokół niego wywołując FxCop bezpośrednio za pomocą exec zadanie. Podam tylko najważniejsze informacje, pomijając specyfikację niektórych właściwości, mam nadzieję, że nazwy są jasne.

I stworzył ItemGroup z bibliotek DLL wyjściowych FilesToAnalyze i doprowadza go do FxCop w sposób podobny do:

<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> 

mogłem następnie określić liczbę błędów w wyjściu za pomocą zadania extensionpack:

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

i stworzyć krok w przeciwnym razie zbudować dla każdego błędu:

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

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

Wykonując w ten sposób analizę kodu na serwerze kompilacji, uniknęliśmy konieczności osobnego konfigurowania każdego projektu. Odizolowaliśmy to wszystko w osobnym pliku .targets, więc dodanie analizy kodu do rozwiązania było kwestią importowania tego pliku, a być może dostosowania zachowania poprzez ustawienie odpowiednich właściwości.

Answer 2

Miałem, jak sądzę, podobny problem z tempomatem, który nie kompilował się przy użyciu symbolu kompilacji CODE_ANALYSIS, nawet jeśli "Włącz analizę kodu podczas kompilacji (określa stałą CODE_ANALYSIS)" sprawdzono w VS.Net.

Wygląda na to, czy jest to sprawdź czy nie, CODE_ANALYSIS faktycznie nie jawnie dodany do listy symboli kompilację w csproj (nawet jeśli wydaje się w polu tekstowym „warunkowe symbole kompilacji”), tylko <RunCodeAnalysis>true</RunCodeAnalysis> dodaje.

Podczas kompilacji za pośrednictwem VS.Net, automatycznie dodaje się CODE_ANALYSIS, ale nie w przypadku korzystania z MSBuild, który jest wykorzystywany przez Cruise Control.

W końcu zmieniłem w VS.Net "symbole warunkowej kompilacji" z "CODE_ANALYSIS; MySymbol" na "MySymbol; CODE_ANALYSIS". To zmusiło użytkownika do pojawienia się w csproj.