SolutionCop



    Hallo Habr! Das Hauptaugenmerk wird auf der .Net-Entwicklung liegen, dh auf der Verwendung von Microsoft Visual Studio, ReSharper, Nuget usw.
    Ich denke, viele von Ihnen haben großartige Lösungen ( in msdn-solution ) mit vielen Unterprojekten entwickelt. In diesem Fall wurde das Problem der Synchronisierung von Nuget-Paketen, Build-Einstellungen usw. häufig zum Problem. Darüber hinaus wird ReSharper hier schlecht helfen, es sei denn, es wird auch in den vielen verwendeten Bibliotheken verwirrend.
    Um den Quellcode zu überprüfen, wurde eine Open Source-Lösung erstellt - SolutionCop , die kostenlos verwendet werden kann.
    Zunächst möchte ich einige Beispiele nennen, bei denen die Überprüfung unserer Lösungen nicht schaden würde.

    Beispiel 1: Verschiedene Versionen von Nuget-Bibliotheken.


    Es gibt beispielsweise drei Projekte: exe, dll1 und dll2. exe bezieht sich auf beide Bibliotheken, jede von ihnen bezieht sich beispielsweise auf RX. Aber dll1 verwendet RX 2.2.0 und dll2 verwendet RX 2.2.5 . Tatsächlich ist es nicht sofort möglich, einen Fehler zu erhalten, da die Funktionssignaturen mehr oder weniger übereinstimmen. Außerdem sammelt MsBuild Projekte häufig in derselben Reihenfolge. Eine solche Konfiguration kann jedoch zu Problemen führen, die nach der Bereitstellung auftreten, wenn alle Komponententests bestanden wurden (weil sie nur auf ihre Bibliothek verweisen) und wenn der resultierende Satz von Dateien vorbereitet wird.

    Beispiel 2: Ein Projekt verweist direkt auf eine Bibliothek und nicht über Nuget.


    Nehmen wir noch einmal unsere drei Projekte: exe, dll1 und dll2. Nehmen wir an, wir verwenden auch Jetbrains.Annotations, um NotNull / CanBeNull- Code mit Attributen zu versehen und eine schöne statische Analyse zu erhalten. Aber hier ist das Pech: Für dll1 haben wir ehrlich gesagt das Paket Version 9.2.0 heruntergeladen , und in dll2 haben wir ReSharper nur gebeten, einen Link hinzuzufügen, was auch geschah. Infolgedessen ist in der Datei packages.config dll2 kein Paket mit Attributen vorhanden. Wenn also das Projekt in der Reihenfolge dll2 -> dll1 -> exe zusammengestellt wird, wird eine Fehlermeldung ausgegeben, da das Nuget-Paket nur beim Sammeln von dll1 heruntergeladen wird.

    Es gibt noch einige Beispiele, bei denen unterschiedliche Einstellungen in Projekten zu witzigen Problemen führen können. Beispielsweise können Projekte für .Net 4.0 und .Net 4.5 auf dieselben Pakete verweisen, jedoch auf unterschiedliche Bibliotheken in ihnen (siehe Nuget-Hilfe ), was bedeutet, dass wir beim Erstellen von Projekten wieder Spezialeffekte erhalten. Es ist jedoch besser, zu SolutionCop überzugehen.

    Installation


    SolutionCop ist auf Nuget verfügbar und wird auf der Ebene der gesamten Lösung installiert. Nach der Installation des Pakets müssen Sie eine XML-Datei mit den Regeln erstellen, diese konfigurieren und den Tester in die Erstellungsprozedur auf CI integrieren .
    Schritt für Schritt:
    1. Wir erstellen eine XML-Datei mit den Regeln (wir überprüfen den SolutionCop selbst):

      SolutionCop.exe -s "C:\git\SolutionCop\src\SolutionCop.sln"

      Nach diesem Befehl wird die SolutionCop.xml-Datei neben der SLN-Datei angezeigt. Es werden alle Regeln aufgelistet, aber sie sind alle deaktiviert. Wir werden sie später betrachten.
    2. Wir konfigurieren den CI-Server so, dass SolutionCop bei jedem Build startet (eine Lösung mit 100 Projekten wird 3-4 Sekunden lang überprüft). Für TeamCity können Sie den Status sogar in einem bequemeren Format veröffentlichen. Für alle anderen müssen Sie die Fehlerausgabe lesen. Die Anwendung gibt 0 zurück, wenn alle Regeln erfolgreich ausgeführt wurden. Die Befehlszeile für TeamCity:

      SolutionCop.exe -s "C:\git\SolutionCop\src\SolutionCop.sln" -b TeamCity --suppress-success-status-message.

      Das letzte Argument ist erforderlich, wenn TeamCity den Status von Komponententests nicht schreibt (obwohl sie später ausgeführt wurden). Die Ausgabe von SolutionCop wird deaktiviert, wenn alle Regeln befolgt werden.

    Die Regeln


    Also, SolutionCop ist konfiguriert, es untersucht nun die Lösung, überprüft aber nichts. Daher werde ich die Regeln auflisten, die sich als nützlich erweisen können. Eine ausführliche Beschreibung ihrer Verwendung findet sich auf GitHub , ich werde einfach die interessanten Dinge auflisten. Natürlich können Sie für jede Regel Ausnahmen usw. festlegen.
    • WarningLevel . Überprüft, ob alle Projekte eine Warnstufe haben, die nicht niedriger als die angegebene ist.
    • TreatWarningsAsErrors . Angrenzend an den vorherigen. Synchronisiert auch die Kompilierungseinstellung .
    • TargetFrameworkVersion . Synchronisiert die .Net-Version für alle Projekte
    • SuppressWarnings . Synchronisiert die Liste der Warnungen, für die der Compiler ein Auge zudrücken wird.
    • FilesIncludedIntoProject . Überprüft, ob alle Dateien im Projektordner in diesem Projekt enthalten sind (die Erweiterung wird zusätzlich angegeben). Eine unglaublich nützliche Regel. Zum Beispiel, einmal mit der falschen Git-Zusammenführung, fiel ungefähr ein Drittel der Dateien aus einem Projekt mit Unit-Tests. Dies wurde natürlich nicht sofort bemerkt, bis dahin hatten wir bereits einige Bugs verpasst. Hilft auch beim Löschen des Repositorys, um zu vermeiden, dass viele Dateien hängen bleiben, die von niemandem verwendet werden.
    • ReferenceNuGetPackagesOnly . Verbietet das dynamische Verknüpfen mit Bibliotheken, die nicht als NuGet-Pakete hinzugefügt wurden. Tatsächlich ist dies eine Korrektur von Beispiel 2 oben.
    • NuGetPackagesUsage . Definiert Nuget-Pakete, die verwendet werden können. Diese Einstellung wird für Aufgaben benötigt, bei denen das Produkt über mehrere Befehle verfügt, von denen jeder ein eigenes Repository hat und die sich aufeinander sowie auf einige gemeinsame Komponenten beziehen. Um Probleme beim Kombinieren von Code zu vermeiden, können Sie allgemeine Regeln für alle definieren: Welche Versionen von Paketen können Sie verwenden? In diesem Fall werden alle Regeln getrennt vom Code in einem separaten Repository gespeichert.
    • SameNuGetPackageVersions . Verbietet die Verwendung verschiedener Nuget-Pakete in der Lösung. Korrektur des Fehlers aus Beispiel 1.
    • NuGetAutomaticPackagesRestore . Überprüft, ob alle Projekte während des Erstellungsprozesses Nuget-Pakete wiederherstellen. Andernfalls kann eine andere Kompilierungsreihenfolge auf dem CI-Server dazu führen, dass Nuget-Pakete nicht rechtzeitig geladen werden, da einige Projekte die Tatsache genutzt haben, dass andere Projekte ihre Abhängigkeiten laden.


    Tatsächlich gibt es in SolutionCop eine Reihe anderer Regeln, die zur Bereinigung des Codes beitragen können. Ich habe versucht, diejenigen aufzulisten, die möglicherweise von fast jedem benötigt werden, der auf .Net entwickelt.

    Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte komm rein .

    Und wie überprüfen Sie Ihren Code nach einem Commit automatisch?

    • 71,4% kontinuierliche Builds 45
    • 53,9% Kontinuierliche Komponententests 34
    • 36,5% Kontinuierliche Integrationstests 23
    • 36,5% Statische Code-Analysatoren (z. B. StyleCop) 23
    • 6,3% Projektvalidatoren (d. H. SolutionCop oder Äquivalente) 4
    • 7,9% Sonstiges (in Kommentaren) 5

    Jetzt auch beliebt: