Zum Inhalt springen

First analysis in 5 minutes (after installation)

From "account created, CLI installed" to "running against your solution" in five minutes.

Updated on 2026-07-13

This guide assumes you have both:

  1. An active account — see Registration and trial, two minutes.
  2. The CLI available locally — see Windows installer or Standalone CLI, allow about ten minutes for the initial setup including license configuration.

From there the run described here takes about five minutes.

If any codecharter command exits with code 6, no valid license was found — revisit the license configuration from the installation guide.

We will walk through this once using a real solution. Custom rules are not required for the first run — a restored profile from your .codecharter/config.yml is enough to get started.

1. Test the CLI

codecharter --version

If this outputs a version number, the CLI is available. If you get "command not found", the CLI is not yet installed — see Installation.

cd ~/code/your-solution
ls *.sln

CodeCharter analyzes at solution level. If there is no .sln or .slnx file you can point it at a single project, but solution is the default case.

3. Provide rules

CodeCharter needs rules to analyze against. The usual source is the profiles in your .codecharter/config.yml, resolved against the portal — run codecharter restore to fetch them into the local cache. Releases no longer ship a bundled rule set.

You can also keep rules in the repository: declare the directory under rules: in the same .codecharter/config.yml (codecharter config add rules rules). codecharter init creates a rules/ directory with two example rules and declares it for you. Profiles and declared directories add up; a directory is never picked up just because it exists.

If the config declares no rule source, analyze stops with exit code 2 and says how to declare one.

Both kinds live in your repository's .codecharter/config.yml: platform rule profiles under profiles:, local .ccr directories under rules:. CodeCharter finds this file by walking up from the analysed file. (The .codecharter/cache/ directory in your repo is only the download cache for profile bundles, not a configuration location.)

4. Start the analysis

codecharter analyze YourSolution.sln --output console

This scans your solution against the resolved rules. The duration depends on the size of your solution; every run loads and analyzes the full solution from scratch.

You will see something like:

  --- 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

Before the results, a Rules: line on stderr names every rule source the run read, with its rule count, for example Rules: 247 from codeguard/csharp-all@1.2.0, 2 from rules.

By default, any finding (including warnings) causes exit code 1. Exit code 0 means zero findings at or above the active severity threshold. Use --fail-on warn or --fail-on error to raise the bar explicitly. See Exit Codes for details.

5. JSON output for further processing

codecharter analyze YourSolution.sln --output json --output-file findings.json

This writes a machine-readable file. Format details under Output formats.

What's next