Use a Command Line build step with a custom script. The agent must have the .NET 9 SDK installed (or use a Docker wrapper image with the SDK). The script below runs in bash; adjust the shebang or runner type for Windows agents.
If your repository is hosted on GitHub and only the build runs on TeamCity, you can additionally publish a branded CodeCharter check run and PR comment from this build — see Publish checks from any CI.
TeamCity build step (Command Line):
#!/bin/bash
set -e
# Download
curl -sSL -H "Authorization: Bearer %env.CODECHARTER_API_KEY%" \
-o codecharter.tar.gz \
https://codecharter.tools/api/v1/cli/linux-x64/1.0.12
mkdir -p codecharter-bin && tar -xzf codecharter.tar.gz -C codecharter-bin
chmod +x codecharter-bin/codecharter
# Run the analysis (console output)
codecharter-bin/codecharter analyze MySolution.sln \
--fail-on error \
--output console \
2>&1 | tee codecharter.log
# Optionally publish as artifact
echo "##teamcity[publishArtifacts 'codecharter.log']"
Replace MySolution.sln with the path to your .sln, .slnx, or .csproj file.
For machine-readable reports, add --output json:codecharter.json or
--output sarif:codecharter.sarif and publish those files as artifacts instead of
(or alongside) the console log.
Because the script runs with set -e, the build fails when analyze exits
non-zero: exit code 1 means findings at or above the --fail-on level, 2 a
usage error, 3 the solution could not be loaded, and 6 a license error.
API key
In TeamCity: Project → Parameters → Environment variable CODECHARTER_API_KEY,
type "Password". Store it at project level so all build configurations can access it.
The analysis requires a license. With CODECHARTER_API_KEY set in the build
environment, the CLI automatically obtains a short-lived license from the portal
at the start of the run; no further setup is needed. If no valid license is
available, the CLI exits with code 6.
Caching
TeamCity has no built-in file cache mechanism equivalent to GitHub Actions'
actions/cache. The .codecharter/cache/ directory next to your solution, which
holds the rule bundles downloaded by codecharter restore, will not automatically
persist between builds on a clean agent.
To cache the CodeCharter cache directory, you need a pinned, non-ephemeral agent that keeps its workspace between builds. Disable the clean checkout option in the build configuration so the work directory persists.
Without a persistent workspace, codecharter restore downloads the rule bundles
again on every build. With a warm cache, the run skips that download.
Self-hosted agents
Works without any changes. The agent needs internet access to
codecharter.tools, or you can mirror the release archive into a
local artifact repository. Note that the CLI still contacts the portal at run
time to obtain its short-lived license from your API key; for fully offline
agents, provide a codecharter.license file instead (for example via the
--license flag).