Skip to content

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: without the --rules flag, the CLI looks for a rules/ directory in the current working directory. codecharter init creates one with two example rules to get you going.

If neither profiles nor a local rules/ directory provide any rules, analyze stops with exit code 2 and the message "No rules directory found".

For your own configuration there are two places: local rules are .ccr files in a rules/ directory, and platform rule profiles are configured in your repository's .codecharter/config.yml. CodeCharter finds this file by walking up from the analysed file. Profiles are the recommended path going forward — runs on default or local rules print a [DEPRECATION] notice on stderr pointing to them. (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

When running on default or local rules you will also see the [DEPRECATION] notice on stderr mentioned in step 3; it does not affect the analysis result.

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