Dieser Leitfaden setzt voraus, dass du beides hast:
- Einen aktiven Account (siehe Registrierung und Trial, zwei Minuten).
- Die CLI lokal verfügbar (siehe Windows-Installer oder Standalone-CLI, rechne 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 deiner
.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, kannst du 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 deiner .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: Deklariere das Verzeichnis unter
rules: in derselben .codecharter/config.yml
(codecharter config add rules rules). codecharter init legt ein
rules/-Verzeichnis mit zwei Beispielregeln an und deklariert es für dich.
Profile und deklarierte Verzeichnisse addieren sich; ein Verzeichnis wird nie
aufgenommen, nur weil es existiert.
Deklariert die Config keine Regelquelle, bricht analyze mit Exit-Code 2 ab
und sagt, wie du eine deklarierst.
Beide Arten stehen in der .codecharter/config.yml deines Repositorys:
Plattform-Regelprofile unter profiles:, lokale .ccr-Verzeichnisse unter
rules:. CodeCharter findet diese Datei, indem es von der analysierten Datei
aus nach oben sucht. (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
Vor den Ergebnissen nennt eine Rules:-Zeile auf stderr jede Regelquelle,
die der Lauf gelesen hat, mit ihrer Regelanzahl, zum Beispiel
Rules: 247 from codeguard/csharp-all@1.2.0, 2 from rules.
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