Ich habe VS 2010 Professional (was im Gegensatz zu Premium nicht den Zugriff auf die Codeanalyse-Konfiguration innerhalb der IDE beinhaltet) und a C # 4-Lösung mit vielen Dutzend Projekten. Ich möchte statische Code-Analysen als Teil der Lösungszusammenstellung durchführen.
Die möglichen Wege, die ich mit Hilfe von SO und Google identifiziert habe, sind:
Bearbeiten Sie alle .csproj in der Lösung, um einen Aufruf des eigenständigen FxCop 10 als Post-Build-Ereignis einzubeziehen. Vorteile: passiert bei jedem Kompilieren für jedes neu erstellte Projekt. Contra: Muss zusätzliche Maßnahmen ergreifen, um sicherzustellen, dass neue Projekte diese Spezifikation haben
Erstellen Sie ein neues Projekt oder identifizieren Sie ein vorhandenes Projekt, das aufgrund seiner Projektabhängigkeiten immer als letztes erstellt wird. Geben Sie (nur) diesem Projekt ein Post-Build-Ereignis, das FxCop auf allen Assemblys im (gemeinsamen) Ausgabeordner ausführt. Vorteile: nur eine Datei zum Aktualisieren und weniger Möglichkeit, dass zukünftige Projekte nicht analysiert werden. Nachteile: Die Unwägbarkeiten von Build-Abhängigkeiten können bedeuten, dass dies nicht funktioniert
Aktualisieren Sie die VS-Instanzen aller Entwickler mit einem Add-In oder einem Makro, das FxCop nach jedem Build ausführt. Ich mag diese Idee überhaupt nicht.
Gibt es noch andere Optionen, die deutlich besser sind als die oben genannten? Gibt es irgendwelche Einschränkungen oder Beobachtungen, die ich beachten muss, um eine der oben genannten Arbeiten zu machen?
Ich möchte auch, dass FxCop als Teil eines Builds mit MSBuild 4.0 -powered auf einem Build-Server ausgeführt wird. Welche der Optionen erlaubt mir Code-Analyse-Regelsätze zwischen Desktop-Kompilierung und Bulid-Server-Kompilierung wiederzuverwenden?
Ich habe bereits verwandte, aber nicht identische bereits bestehende Fragen gelesen, einschließlich:
Um FxCop als Teil des Build-Scipt (MSBuild) zu integrieren, verwende ich den FxCop-Task von MSBuild.Community.Tasks . Mit FxCop erstelle ich ein FxCop-Projekt (FxCopProject.FxCop), das die zu verwendenden Regeln und die zu untersuchenden Baugruppen definiert.
%Vor%Ich habe Hudson als Build-Server verwendet, der nach dem Erstellen von .NET-Anwendungen eine Codeanalyse durchführen würde. Um es für diesen Zweck zu verwenden, müssen Sie zwei Plugins installieren:
Hudson müsste für die Ausführung von FxCop und StyleCop konfiguriert werden, aber das ist nicht sehr schwer mit Batch-Dateien. Der Vorteil besteht darin, dass keine Ihrer Projektdateien konfiguriert werden muss, da die Codeanalyse extern durchgeführt wird. das heißt, nicht über Visual Studio.
Sie können Hudson so konfigurieren, dass die Codeanalyse als tägliche Aufgabe oder sogar bei jeder Änderung an Ihren Anwendungen durchgeführt wird. Anschließend konnte jeder in Ihrem Entwicklungsteam die Ergebnisse der Codeanalyse über Hudson anzeigen, um festzustellen, ob sie Verstöße begangen haben.
Ich habe FxCop für eine Weile nicht benutzt, aber wenn du viele Projekte hast, vermute ich, dass es für jedes Projekt einmal und nicht nur einmal am Ende laufen wird, wird es schmerzhaft sein. Sie könnten versuchen (oder zumindest von beginnen) etwas wie dies . Kurz gesagt, Sie haben ein Uber-Projekt mit Zielen, die von der Erstellung Ihrer gesamten Lösung abhängen, gefolgt von FxCop (oder Komponententests usw.). Sie rufen das Uber-Projekt mit einer Batch-Datei aus dem Projektmappen-Explorer auf. p>
Es ähnelt Ihrem zweiten Vorschlag, hat aber keine Abhängigkeit von der Erstellungsreihenfolge und erfordert nicht, dass Sie an neuen Projekten fummeln. Leider bricht seine aktuelle Inkarnation die normalen Abkürzungen für den Aufbau innerhalb von VS, und es wird wahrscheinlich leicht zufällig zu umgehen sein, aber es könnte möglich sein, es zu verfeinern.
Es könnte auch sauberer und besser in VS integriert sein, um ein MSBuild-Ziel für die Ausführung von FxCop zu verwenden, als einen Post-Build-Schritt.
Eine Alternative zu FxCop wäre die Verwendung des Tools NDepend, mit dem Code-Regeln über C # LINQ-Abfragen (nämlich CQLinq)
Mehr als 200 Coderegeln werden standardmäßig vorgeschlagen. Das Anpassen vorhandener Regeln oder das Erstellen eigener Coderegeln ist dank der bekannten C # LINQ-Syntax problemlos möglich.
Regeln können in in Visual Studio verifiziert werden und zur Build-Prozesszeit in generierter HTML + JavaScript-Bericht .
Erstellen Sie eine benutzerdefinierte Buildaktivität (die basierend auf einer Eigenschaft ausgeführt wird, die wir über die Builddefinition festlegen):
Aktualisiert alle csproj-Dateien, um die Eigenschaft "
hinzuzufügenwahr
Speichern Sie die csproj-Datei.
Dies bedeutet, dass wir kontrollieren können, wann die Codeanalyse ausgeführt werden muss oder nicht. Wir müssen es nicht jedes Mal ausführen, wenn wir den Code erstellen.
Bitte lesen Sie, dass Sie nicht die Premium-VS haben, aber Sie können denselben Prozess verwenden, um das Build-Ereignis der csproj-Datei nach der Build-Zeit zu aktualisieren.
Ich weiß, das ist eine alte Frage, aber die beste Option IMO ist es, SonarQube mit dem C # -Plugin zu verwenden, um Ihre Analyse zu machen. Dies behandelt FxCop als eine der Analysemöglichkeiten, sowie das Ausführen von StyleCop- und ReSharper-Analysen (mit dem kostenlosen Befehlszeilen-Runner) und das Kompilieren in einer Webschnittstelle.
Es dauert eine Weile, bis das erste Projekt eingerichtet ist, aber die Einrichtung nachfolgender Projekte ist sehr ähnlich und kann von Ihrem CI-Server ausgelöst werden.
Tags und Links visual-studio-2010 msbuild code-analysis fxcop