Zum Inhalt springen

Warum die Solution nicht lädt: Exit-Code 3 und Prüfschritte

Was Exit-Code 3 bedeutet, warum ein Lauf still weniger Methoden analysiert als erwartet, und die Prüfschritte in der richtigen Reihenfolge.

Aktualisiert am 2026-09-01

codecharter analyze braucht einen funktionierenden MSBuild-Workspace, um eure .sln, .slnx oder .csproj zu öffnen, bevor auch nur ein Typ gelesen werden kann. Geht dieser Schritt schief, zeigt sich das auf zwei Arten: als harter Fehler mit Exit-Code 3, oder leiser dadurch, dass der Lauf "erfolgreich" durchläuft, aber weniger Code analysiert hat als er sollte.

Exit-Code 3: der Lauf bricht ab

Analysis failed: <exception message>

Exit-Code 3 bedeutet, dass die Solution oder ein Projekt überhaupt nicht geladen werden konnte: der Lauf erreicht die Regelauswertung gar nicht erst. Der häufigste Auslöser ist ein Pfad, der nicht existiert: Wenn ihr direkt auf eine bestimmte .sln/.csproj-Datei zeigt, die es nicht gibt, wirft der Workspace beim Öffnen einen Fehler.

Das unterscheidet sich davon, ein Verzeichnis (oder nichts) anzugeben, das gar kein Projekt enthält: codecharter analyze durchsucht das Verzeichnis zunächst nach einer .sln, .slnx oder .csproj, und wenn es keine findet, beendet es sich mit Code 2 ("No .sln, .slnx, or .csproj file was found under ..."), noch bevor überhaupt versucht wird, etwas zu laden. Exit-Code 3 betrifft speziell ein Ziel, das gefunden, aber nicht geöffnet werden konnte.

Die vollständige Tabelle findet ihr unter Exit-Codes, die Zusammenfassung des Befehls unter codecharter analyze.

Der leisere Fehler: weniger Methoden als erwartet

Ein Projekt kann auch dann erfolgreich über den Design-Time-Build öffnen, wenn sein eigenes Package-Restore fehlt oder veraltet ist. CodeCharter behandelt das nicht als Ladefehler: Die Analyse läuft weiter, und der Exit-Code richtet sich weiterhin nach den Findings. Aber jede aus diesem Projekt extrahierte Tatsache kann falsch sein, weil dessen Compilation die eigenen Referenzen nicht auflösen konnte. Insbesondere die Klassifizierung von Interface-Implementierungen hängt davon ab, den Interface-Typ aufzulösen: Eine Methode, die IEquatable<T> oder ein eigenes Interface implementiert, kann übersehen werden, was wiederum jede darauf aufbauende Regel betrifft.

Symptome, auf die ihr achten solltet:

  • codecharter analyze --verbose meldet spürbar weniger Typen oder Methoden, als ihr für die Größe der Solution erwartet.
  • Findings, die von Interface-Implementierung abhängen (oder davon, dass ein Typ überhaupt ein bestimmtes Interface implementiert), sehen falsch aus oder fehlen ganz.
  • codecharter analyze --progress gibt eine Zeile aus, die das betroffene Projekt benennt und darauf hinweist, dass dessen NuGet-Restore fehlen oder veraltet sein könnte.

Da sich dabei am Exit-Code nichts ändert, zeigt sich dieser Fehlermodus nur in der Ausgabe des Laufs selbst: Prüft --verbose (und --progress für die Details je Projekt) immer dann, wenn die Anzahl der Findings verdächtig niedrig wirkt.

Prüfschritte in der Reihenfolge

  1. Den Pfad bestätigen. Gebt den Pfad zur .sln, .slnx oder .csproj-Datei explizit an, statt euch auf die Verzeichnis-Erkennung zu verlassen:

    codecharter analyze path/to/YourSolution.sln

  2. Restore, dann die ganze Solution bauen. Ein unvollständiges oder veraltetes Restore ist die häufigste Ursache für den leiseren Fehler oben. Führt vor der Analyse ein vollständiges Restore und einen Build durch, genau wie CI es bei einem sauberen Checkout tut:

    dotnet restore
dotnet build
codecharter analyze path/to/YourSolution.sln

    Analysiert die .sln, nicht eine einzelne .csproj, wenn die Solution mehrere Projekte hat: So durchlaufen alle Projekte denselben Restore- und Build-Durchgang, bevor die Analyse startet.

  3. Das .NET SDK bestätigen. CodeCharter öffnet den Workspace über das MSBuild-Tooling des .NET SDK. Ist kein SDK installiert, oder fehlt das SDK/Workload für das Ziel-Framework der Solution, kann der Workspace gar nicht erst erzeugt werden. Prüft, was installiert ist:

    dotnet --info
dotnet --list-sdks

  4. Die --verbose- und --progress-Ausgabe lesen. --verbose meldet das verwendete Rules-Verzeichnis und die Gesamtzahl der gefundenen Typen und Methoden; eine Zahl deutlich unter eurer Erwartung deutet auf den leiseren Fehler oben hin. Mit --progress seht ihr zusätzlich eine Zeile je analysiertem Projekt, einschließlich eines Hinweises, wenn das Restore eines Projekts kaputt aussieht:

    codecharter analyze path/to/YourSolution.sln --verbose --progress 2> codecharter.log

Schlägt der Lauf nach diesen Prüfungen immer noch fehl, sammelt das Log und schickt es uns, siehe Logs sammeln.