Dieser Leitfaden setzt voraus, dass Sie beides haben:
- Einen aktiven Account (siehe Registrierung und Trial, zwei Minuten).
- Die CLI lokal verfügbar (siehe Windows-Installer oder Standalone-CLI, rechnen Sie mit etwa zehn Minuten beim ersten Setup inklusive Lizenz-Hinterlegung).
Ab da nimmt der hier beschriebene Lauf rund fünf Minuten.
Wenn ein codecharter-Befehl mit Exit-Code 6 endet, wurde keine gültige
Lizenz gefunden. In dem Fall bitte die Lizenz-Einrichtung aus der
Installationsanleitung noch einmal prüfen.
Wir gehen das einmal an einer echten Solution durch. Eigene Regeln sind
für den ersten Lauf nicht nötig, ein wiederhergestelltes Profil aus Ihrer
.codecharter/config.yml reicht für den Einstieg.
1. CLI testen
codecharter --version
Wenn das eine Versionsnummer ausgibt, ist die CLI verfügbar. Falls "command not found" erscheint, ist die CLI noch nicht installiert. Anleitung unter Installation.
2. In das Solution-Verzeichnis wechseln
cd ~/code/your-solution
ls *.sln
CodeCharter analysiert auf Solution-Ebene. Wenn keine .sln- oder .slnx-Datei
vorhanden ist, können Sie auf ein einzelnes Projekt zeigen, aber
Solution ist der Default-Fall.
3. Regeln bereitstellen
CodeCharter braucht Regeln, gegen die analysiert wird. Die übliche Quelle sind
die Profile in Ihrer .codecharter/config.yml, aufgelöst gegen das Portal. Mit
codecharter restore werden sie in den lokalen Cache geladen. Releases liefern
keinen gebündelten Regelsatz mehr mit.
Regeln können auch im Repository liegen: Ohne das Flag --rules sucht die CLI
nach einem rules/-Verzeichnis im aktuellen Arbeitsverzeichnis. codecharter init
legt eines mit zwei Beispielregeln an.
Liefern weder Profile noch ein lokales rules/-Verzeichnis Regeln, bricht
analyze mit Exit-Code 2 und der Meldung "No rules directory found" ab.
Für eigene Konfiguration gibt es zwei Orte: Lokale Regeln sind
.ccr-Dateien in einem rules/-Verzeichnis, Plattform-Regelprofile
werden in der .codecharter/config.yml Ihres Repositorys konfiguriert.
CodeCharter findet diese Datei, indem es von der analysierten Datei aus nach
oben sucht. Profile sind der empfohlene Weg; Läufe mit Default- oder lokalen
Regeln geben einen [DEPRECATION]-Hinweis auf stderr aus, der dorthin zeigt.
(Das .codecharter/cache/-Verzeichnis im Repo ist nur der Download-Cache für
Profil-Bundles, kein Konfigurationsort.)
4. Analyse starten
codecharter analyze YourSolution.sln --output console
Das scannt die Solution gegen die aufgelösten Regeln. Die Dauer hängt von der Größe der Solution ab; jeder Lauf lädt und analysiert die komplette Solution neu.
Die Ausgabe sieht etwa so aus:
--- Warning (2) ---
WARN [Async] Async method without CancellationToken
Acme.Web.Services.OrderService.SyncOrdersAsync
src/Acme.Web/Services/OrderService.cs:42
↳ Add 'CancellationToken cancellationToken = default' as the last parameter
WARN [Testability] Direct DateTime/DateTimeOffset usage instead of TimeProvider
Acme.Web.Services.PriceCalculator.GetPrice
src/Acme.Web/Services/PriceCalculator.cs:18
↳ Inject TimeProvider via constructor and call GetUtcNow() or GetLocalNow()
────────────────────────────────────────
2 violations (2 warnings)
Analyzed 412 types, 3187 methods in 28.4s
Bei Läufen mit Default- oder lokalen Regeln erscheint zusätzlich der in
Schritt 3 erwähnte [DEPRECATION]-Hinweis auf stderr; er hat keinen
Einfluss auf das Analyseergebnis.
Per Default verursacht jedes Finding (auch Warnungen) Exit-Code 1. Exit-Code 0
bedeutet: keine Findings auf oder über dem aktiven Severity-Schwellwert. Mit
--fail-on warn oder --fail-on error lässt sich die Schwelle anheben. Details
unter Exit-Codes.
5. JSON-Output für weitere Verarbeitung
codecharter analyze YourSolution.sln --output json --output-file findings.json
Das schreibt eine maschinenlesbare Datei. Format-Details unter Output-Formate.
Was als nächstes
- Erste eigene Regel schreiben: siehe Erste eigene Regel
- Ein Finding fixen: siehe Erstes Finding fixen
- In die CI einbauen: siehe GitHub Actions