The matrix below lists the capabilities CodeCharter brings and shows how the most common .NET code quality tools compare. Every row is something CodeCharter does; the other columns reflect each tool's real, current behaviour.
Feature matrix
Legend: ✓ = supported, partial = limited or indirect support, ✗ = not supported.
| Feature | CodeCharter | Roslyn analyzers | SonarQube / Cloud | NDepend | Qodana |
|---|---|---|---|---|---|
| Source never leaves your environment | ✓ | ✓ | self-hosted only | ✓ | ✓ (results go to Qodana Cloud) |
| No server or cloud backend to operate | ✓ | ✓ | ✗ | ✓ | ✗ (Cloud account; Self-Hosted is a server) |
| Standalone CLI you run on demand | ✓ | ✗ (runs inside the build) | ✗ (scanner needs a server) | ✓ | ✓ |
| Custom rules in a text DSL — no C# project, build, or NuGet | ✓ | ✗ (analyzer project + NuGet) | ✗ (Roslyn import or templates) | ✓ (CQLinq) | ✗ (FlexInspect / structural search) |
| Browser-based rule editor with live validation and online spec check | ✓ | ✗ | ✗ | ✗ | ✗ |
| Spec-test custom rules against hit/miss cases — local, CI, and browser, with run history | ✓ | ✗ | ✗ | ✗ | ✗ |
| Architecture and layering rules in the rule language | ✓ | ✗ | partial | ✓ | partial |
| Coupling and OOP metrics (instability, abstractness, cohesion) in the model | ✓ | ✗ | partial | ✓ | ✗ |
| Baseline gate that only fails on new findings | ✓ | ✗ | ✓ | ✓ | ✓ |
| Runs your tests and computes line coverage itself — no separate coverage tool or report import | ✓ | ✗ | ✗ (imports coverlet/dotCover reports) | ✗ (imports reports) | ✗ (imports reports) |
| Author, version, and share rule profiles centrally | ✓ | ✗ | ✓ | ✗ | ✓ (Cloud) |
| Versioned, signed rule profiles with offline / air-gapped bundles | ✓ | ✗ | ✗ | ✗ | ✗ |
| SARIF, JSON, and GitHub-annotation output | ✓ | partial (SARIF via build ErrorLog) | ✓ | partial (SARIF import; own report) | ✓ |
| MCP server so AI coding assistants enforce your rules | ✓ | ✗ | ✓ | ✓ | ✗ |
| Dependency graph queries (overview, neighborhood, blast-radius impact) on the command line and as MCP tools for AI agents | ✓ | ✗ | ✗ | partial (dependency graphs and CQLinq queries; no CLI/MCP query surface) | ✗ |
| Central audit log of rule, profile, and API-key activity, exportable as CSV | ✓ | ✗ | ✓ (Enterprise) | ✗ | partial (Cloud usage/license reporting) |
| Opt-in usage insights with no source code and no PII | ✓ | ✗ | ✓ (server dashboards) | ✓ (dashboards) | ✓ (Cloud dashboards) |
| Flat organization plans in team-size tiers (monthly or yearly), no metered per-seat price | ✓ | free / OSS | per lines of code | per seat | per contributor (from 3) |
When CodeCharter is the right choice
When you want to enforce custom rules without maintaining C# analyzer projects. CodeCharter rules live in a text file, with no build or NuGet lifecycle.
When you want to test your rules like code. Every rule can carry hit/miss spec cases that run locally, in CI, and in the browser, so a rule change that stops matching the right code fails fast.
When you want to author rules without leaving the browser. The portal editor validates the DSL live and runs an online spec check before you publish.
When you want to enforce architecture and layering in the build. Coupling and dependencies are part of the model, and layering rules are written directly in the DSL.
When you share rules across teams and CI but still need air-gapped builds. Profiles are versioned and signed, and can be consumed as offline bundles.
When you don't want to operate another server. Analysis runs locally, source code never leaves your environment, and there is no dashboard, database, or license server for you to host or operate.
When you want pull-request gates scoped to changed lines. With --diff or
--git-ref, both the reported findings and the fail gate apply only to the
lines a change touches, and the GitHub Action can publish the results as
annotations on the pull request.
When you want coverage from the same tool that gates your findings.
codecharter coverage discovers and runs your test projects and computes line
coverage on its own — no coverlet setup, no report import. The gate can hold the
whole repository to a threshold or, with --git-ref, just the lines a change
touches, and the portal serves coverage, findings, and test badges for your
README without a third-party badge service. See
codecharter coverage.
When you want rule support in the editor. The VS Code extension brings
completions, diagnostics, and spec runs for .cgr rule files into the editor
and can analyze the open workspace.
When you want a flat plan instead of a metered per-seat price. CodeCharter is licensed per organization, monthly or yearly, in plan tiers sized by team (Starter up to 5, Team up to 10, Business up to 25 developer seats, Enterprise without a cap). Within a tier the price does not change as developers join, and there is no per-seat usage reporting — the tier limit is simply enforced through organization membership. See what counts as a developer seat.
Everything on this page can be evaluated with a free 7-day trial that starts automatically on registration — no payment details required.
How it fits together
CodeCharter does not replace every tool above. A practical stack for a typical .NET team:
- EditorConfig for style settings in the editor.
- Microsoft.CodeAnalysis.NetAnalyzers as the Roslyn baseline for language and style.
- CodeCharter for custom conventions, architecture and layering, complexity thresholds, and everything that goes beyond standard rule sets.
For the narrow case of layering assertions inside your unit test suite, libraries such as ArchUnitNET and NetArchTest let you express dependency rules as C# tests. They cover the test-library angle; CodeCharter adds a standalone analyzer, a shared rule language, spec testing, and CI gating on top of it.