Verbesserung der Codeanalyse

Question

Statische CA lässt die Lösung langsamer bauen. In meinem Fall> 2x langsamer als ohne CA. Wir können es deaktivieren, aber das ist eine schlechte Entscheidung, seine Macht zu verlieren. Was können wir tun?

Lassen Sie uns zuerst sehen, wie CA funktioniert.

Sie bauen Lösung. Bei jedem Projekt, das nach dem Msbuild-Kompilierungsziel erstellt wird, wird fxcopcmd.exe mit Pfaden zu Assemblys aufgerufen, die analysiert werden sollen. fxcopcmd. generiert CA-XML-Protokoll, das von VS (oder möglicherweise Ausgabestrom) verwendet wird. fxcopcmd.exe lädt Assemblys (fast) und analysiert sie synchron, so dass nur eine CPU geladen ist und 3 (in meinem Fall) nichts tun. Erst nachdem CA beendet ist, wird das nächste Projekt in der Projektabhängigkeitskette aufgebaut.

Also der schwache Ort in CA waren wir können es verbessern - es parallel dazu zwingen, alle CPUs zu verwenden.

ich eine solche Lösung

zu fälschen fxcopcmd.exe machen sehen, die Parameter von MSBUILD nehmen, sie erinnern und sofort msbuild berichten, dass alle in Ordnung ist, und es gab kein Fehler (über CA xml.log, oder erfolgreiche Datei, oder vielleicht Stream ..). Also wird MSBUILD das nächste Projekt erstellen und zu diesem Zeitpunkt werden wir real fxcopcmd.exe mit den gespeicherten Parametern aufrufen ... wenn MSBUILD fxcopcmd.exe beim nächsten Projekt aufrufen wird - wir werden noch einmal fxcopcmd.exe aufrufen ... so wird es geschehen wenige Prozesse, die alle CPUs laden. Nachdem die fxcopcmd.exe fertig ist, können wir unser MSBUILD-Ziel aufrufen, das nur CA-Ziel von microsoft.common.targtets ohne Kompilierung aufruft und unsere gefälschte fxcopcmd.exe meldet sofort Ergebnisse (CA ist zu diesem Zeitpunkt fertig und wir haben Log) zu MSBUILD-VS.

Was denkst du? Wird dies CA beschleunigen? Warum Microsoft hat nicht solche Mitarbeiter und verwenden nur eine CPU in CA?

Answer 1

Ich habe einmal eine similar question on Connect and got a reply directly from the team gefragt. Auf dem ALM-Gipfel im Jahr 2012 diskutierte ich das Thema und es gab eine Reihe von Gründen (in keiner bestimmten Reihenfolge)

• Die Code-Analyse-Engine wird höchstwahrscheinlich ersetzt werden, sobald Projekt Roslyn das Visual Studio-Produkt integriert sich in. Roslyn bietet Echtzeitanalyse (wie Resharper) und die Möglichkeit, gefundene Probleme zu "reparieren".
• Die Engine ist sehr CPU-intensiv und verwendet bereits mehrere CPUs. Daher kann es nicht so hilfreich sein, mehrere Instanzen auszuführen, wie Sie vermuten. Außerdem kann fxcop sehr I/O-intensiv sein (Laden von Assemblys, PDBs und anderen Dateien), was sich nur verschlimmern würde, wenn Sie mehrere Instanzen gleichzeitig laden.
• Die Build-Engine benötigt Zugriff auf die Build-Ausgabe. Zur Referenzierung, aber auch für andere Aufgaben. Daher muss es wissen, dass die Dateien nicht mehr verwendet werden, wenn eine Aufgabe abgeschlossen ist. Wenn Sie z. B. eine Aufgabe hinzufügen, bei der eine Anzahl von Assemblys zusammengelegt wird und die alten anschließend entfernt werden, muss auf diese Dateien zugegriffen werden. Gleiches gilt für einfache Aktionen für move/package/etc.
• Die Möglichkeit, den Build zu früh zu beenden, wenn ein Codeanalyseproblem (auf Level = Fehler) gefunden wird, funktioniert nicht, da Sie die Ergebnisse nur am Ende sammeln. Möglicherweise verursachen Sie, alles zu bauen, nur um herauszufinden, dass Sie das Endergebnis nicht verwenden können.

Wie Sie hier in this MSDN forum post sehen können, FXCop selbst nutzt bereits mehrere Threads und (zumindest in den Regeln, die mit 2010 ausgeliefert) gibt ein paar Probleme mit Parallelität sind bereits, dass uns dazu bringen, Parallelität zu deaktivieren für FXCop in bestimmte Fälle.Wenn Sie FXCop wollen mehr (oder weniger) Threads zu verwenden, können Sie die fxcopcmd.exe.config Datei bearbeiten:

<FxCopEngineSettings Version="1.32"> 
    <Engines> 
    <Engine Name="Introspection" Enabled="True"> 
     <!-- Change this number to use more (or fewer) threads --> 
     <Threading Count="1" /> 
     <EnableFlowAnalysis>True</EnableFlowAnalysis> 
    </Engine> 
    </Engines> 
</FxCopEngineSettings> 

Obwohl das Forum Post Visual Studio 2008 erwähnt, habe ich diese Fragen auch mit 2010 zu beheben angewendet.

Eine sehr einfache Möglichkeit, FxCop effizienter zu machen, besteht darin, sie einmal aufzurufen, nachdem alle Projekte kompiliert wurden. Dies führt dazu, dass nur alle Symbole und referenzierten Assemblies geladen werden und die Engine die Parallelität maximal nutzen kann. Es gibt einige Probleme damit, wenn Sie eine Lösung haben, die mehrere Zielplattformen und CPUs mischt oder wenn Sie unterschiedliche .rules-Dateien für verschiedene Projekte verwenden möchten.

Oder Sie könnten das gleiche tun, was ich tue, nämlich FxCop für Ihre lokale Lösung zu konfigurieren, aber nicht, dass es für jeden Build ausgeführt wird. Dann überschreiben Sie in Team Foundation Server Team Build (oder einem anderen Build-Server, den Sie möglicherweise verwenden) die Konfiguration für FxCop, um "Immer" auszuführen. Auf diese Weise haben Sie keinen Leistungseinfluss beim Erstellen Ihrer lokalen Lösung. Sie können weiterhin die Codeanalyse für Ihre gesamte Lösung lokal ausführen (über den Menüeintrag "Analysieren"), und der automatische Build kann Sie vor dem Einchecken von Code mit Problemen schützen.