Coverage Analysis with Command-Line Tool

Supported OSs

The tool is available as a .NET command-line tool on Windows (x86, x64, arm64), Linux (x64, arm32, arm64, musl-x64, musl-arm64), and macOS (x64, arm64).

Distribution format

The tool is distributed as a cross-platform framework-dependent .NET tool (requires .NET to be installed). View NuGet package

Install dotCover command-line tool

The main way to install the dotCover command-line tool is to install it as a .NET tool. It's recommended if you want to run coverage analysis locally on your computer or a CI/CD server.

Install dotCover as a global tool for all projects on the computer

Run:
dotnet tool install --global JetBrains.dotCover.CommandLineTools

Install dotCover as a local tool for a specific project/directory

Run:
dotnet tool install JetBrains.dotCover.CommandLineTools --tool-path "some/path"

After the installation, you can run the command-line tool from any directory (if installed globally) or from the directory where it was installed (if installed locally) using the dotCover command. For example:

dotCover help

Configure dotCover command-line tool

To configure the dotCover command-line tool, you can use command-line parameters or a plain-text response file.

For example:

            dotCover cover --xml-report-output AppCoverageReport.xml -- test "C:\MyProject\MainTests.csproj"
        

You can use the same parameter syntax on all OSs.
Parameters should be written in kebab-case, e.g.: --target-executable
Separate parameter name and value with a space, e.g., --target-executable MyApp.exe
Escape paths with spaces using additional double quotes and a backslash, e.g., ... --target-arguments "\"D:\My Projects\My Application\bin\Debug\AppTests.dll"\"
Relative paths are resolved from the working directory.
If no output parameters are specified, the tool will generate a coverage snapshot (.dcvr) by default. To get a report, use --json-report-output or --xml-report-output. To get both, specify --snapshot-output and a report output option.
Use a response file to simplify complex parameter sets, e.g., dotCover cover @args.txt
For the full list of parameters, refer to Command Reference.

Analyze unit test coverage in .NET projects

Open the solution folder.
Build the solution:
dotnet build
Run tests with coverage analysis and get a coverage snapshot:
dotCover cover --snapshot-output snapshot.dcvr -- test --no-build
To get a report instead of or in addition to a snapshot, add a --json-report-output or --xml-report-output parameter:
dotCover cover --xml-report-output report.xml -- test
If you configured dotCover with a response file, specify a path to the file:
dotCover cover @"~/config/config.txt"

Analyze unit test coverage in .NET Framework projects

Make sure your unit test project is built.
Run tests with coverage analysis and get a coverage snapshot. For example, with NUnit:
dotCover cover --target-executable "D:\Program Files\NUnit 2.6\bin\nunit-console.exe" --target-arguments "D:\Projects\TheApplication\bin\Debug\AppTests.dll" --snapshot-output snapshot.dcvr
Here:
- --target-executable – path to the test runner
- --target-arguments – arguments passed to the runner (the compiled unit test assembly). Note that if these arguments contain paths with spaces, you should escape them with additional double quotes and a backslash, for example, ... --target-arguments "\"D:\My Projects\My Application\bin\Debug\AppTests.dll"\"
To get a report instead of or in addtion to a snapshot, add a --json-report-output or --xml-report-output parameter:
dotCover cover --target-executable "D:\Program Files\NUnit 2.6\bin\nunit-console.exe" --target-arguments "D:\Projects\TheApplication\bin\Debug\AppTests.dll" --xml-report-output report.xml
If you configured dotCover with a response file, specify a path to the file:
dotCover cover @"D:\Config\config.txt"

Apply coverage filters

Use filters to exclude specific assemblies, code marked with attributes, or external processes from coverage analysis. Filters help reduce noise and focus results on the code you care about.

--exclude-assemblies <list> – A comma-separated list of assembly names to exclude. Wildcards (*) are allowed. For example:
dotCover cover --exclude-assemblies MyTests,*Helpers
--exclude-attributes <list> – A comma-separated list of fully qualified attribute names. Any code marked with these attributes will be excluded. Wildcards (*) are allowed. For example:
dotCover cover --exclude-attributes System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute
--exclude-processes <list> – A comma-separated list of process names to exclude from coverage analysis. Wildcards (*) are allowed. For example:
dotCover cover --exclude-processes vstest.discovery.engine
You can combine filters provided via command-line arguments and filters defined in response files. dotCover will merge all list values from all sources. For example:
dotCover cover --exclude-assemblies "*.Tests" @filters.txt
In this example, filters.txt might contain:
--exclude-assemblies ThirdPartyLib --exclude-attributes System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute

Analyze coverage for multiple test projects

If your solution contains multiple test projects, you may want to collect code coverage for all of them and generate a single unified report. The recommended approach depends on whether all projects use the same unit testing framework.

Projects use the same test framework

If all test projects in your solution use the same unit testing framework, you can run them together in a single coverage session. This method is only applicable if all projects can be executed via a single dotnet test call. It works for MSTest, xUnit, and NUnit projects that use SDK-style project files.

Build the solution:
dotnet build
Run all tests with coverage and save the snapshot:
dotCover cover --snapshot-output snapshot.dcvr -- test --no-build
To generate a report instead of or in addition to a snapshot, use a report output parameter:
dotCover cover --xml-report-output report.xml -- test --no-build

Projects use different test frameworks

If your solution includes test projects that use different unit testing frameworks (for example, MSTest and NUnit), you need to run coverage for each project separately and then merge the resulting coverage snapshots into a single report.

dotCover: Merging coverage snapshot into a single report

Create a response file for each test project. These files will define how each test is executed and where the snapshot is saved.
args1.txt for TestProject1 (MSTest):
--target-executable "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\MSTest.exe" --target-arguments "TestProject1.dll" --target-working-directory "D:\Projects\MyApp\bin\Debug" --snapshot-output Snapshot1.dcvr
args2.txt for TestProject2 (NUnit):
--target-executable "C:\Tools\NUnit\nunit3-console.exe" --target-arguments "TestProject2.dll" --target-working-directory "D:\Projects\MyApp\bin\Debug" --snapshot-output Snapshot2.dcvr
Run coverage for each project:
dotCover cover @args1.txt dotCover cover @args2.txt
This will generate two snapshot files: Snapshot1.dcvr and Snapshot2.dcvr.
Merge the snapshots into one:
dotCover merge --snapshot-source Snapshot1.dcvr,Snapshot2.dcvr --snapshot-output MergedSnapshots.dcvr
Generate a coverage report from the merged snapshot:
dotCover report --snapshot-source MergedSnapshots.dcvr --xml-report-output CoverageReport.xml

Find symbol files (PDB)

Locating symbol files (PDB) for the target binaries is vital for calculating coverage. If you cover unit tests or cover the startup project, dotCover easily locates symbol files using the structure of the current solution.

By default, dotCover search symbol files in the following places:

in the same directory where the binary file resides,
in the debug directory specified inside the binary file,
in all directories specified in the _NT_SYMBOL_PATH environment variable and in the registry.