TeamCity Cloud
 
2024.12
Get TeamCity Cloud
  1. Configuring Test Reports and Code Coverage
  2. Configuring .NET Code Coverage
  3. JetBrains dotCover

JetBrains dotCover

Edit pageLast modified: 03 November 2024

TeamCity comes bundled with the console runner of JetBrains dotCover. In addition to the bundled version, you can install another version of JetBrains dotCover Command Line Tools.

After choosing the appropriate option in the .NET coverage section of a build step, you will be able to collect code coverage for your .NET project and then view the coverage statistics and detailed coverage report inside the TeamCity web UI.

If you have a license for dotCover and have it installed on a developer machine, TeamCity-collected coverage results can be downloaded and viewed inside Visual Studio with the help of the TeamCity Visual Studio Add-in.

tip

.NET Framework 3.5 or newer must be installed on the agent machine. This is necessary for the bundled dotCover to work. Your project can depend on another .NET Framework version.
dotCover 2018.2 or newer requires .NET Framework 4.6.1 or newer.

dotCover Settings

Path to dotCover Home

Leave this field blank to use the default dotCover. Alternatively, specify the path to the dotCover installed on a build agent.

Filters

Specify a new-line separated list of filters for code coverage. Use +|-:assembly=*;type=**;method=*** to include or exclude assemblies from covered assemblies:

tip

Here, the pipe symbol | represents the OR command, as in regular expressions: use + for including, OR - for excluding.

For example, to run coverage on all MyDemoApp assemblies but not on MyDemoApp.*.Tests, specify the following assembly filters for coverage:
+:MyDemoApp.*
-:MyDemoApp.*.Tests

See also the related blog post.

Attribute Filters

If you do not want to know the coverage data solution-wide, you can exclude the code marked with an attribute (for example, with ObsoleteAttribute) from the coverage statistics. You only need to specify these attribute filters here in the following format: the filters should be a new-line separated list; the -:attributeName syntax should be used to exclude the code marked with the attributes from code coverage. Use the asterisk (*) as a wildcard if needed.
Supported only for dotCover 2.0 or newer.

Additional arguments

Provide a new-line separated list of additional commandline parameters to pass to dotCover.exe.

Note that dotCover coverage engine reports statement coverage instead of line coverage.

Compile and Test in Different Builds

To build a consistent coverage report, dotCover has to be able to find source files under the build checkout directory which should be easy if you build binaries and collect coverage in the same build, or if you use different builds, but they use a snapshot dependency and the same agent as well as the same VCS settings.

If you need to build binaries in one build and collect code coverage in another one using different checkout settings, some additional properties are required. It is assumed that:

  • Build configuration A compiles code with debugging information and creates an artifact with assemblies and .pdb files

  • Build configuration B runs tests with dotCover enabled and has a snapshot dependency on A.

To display the source code in the Code Coverage tab of build results of B, you need to point B to the same VCS root as A to get your source code in an appropriate location (the checkout root) and add an artifact dependency on build from the same chain of A (for dotCover to get the paths to the sources from the .pdb files).

You also need to tell TeamCity where to find the source code. To do this, perform the following:

  1. Add the teamcity.dotCover.sourceBase configuration parameter with the value %teamcity.build.checkoutDir% to the compiling build configuration A.

  2. Add the configuration parameter dotNetCoverage.dotCover.source.mapping to your test configuration B with the value %dep.btA.teamcity.dotCover.sourceBase%=>%teamcity.build.checkoutDir%, where btA is the actual ID of your configuration A.

Standalone dotCover Runner

Starting with version 2024.03, not only you can invoke JetBrains dotCover by enabling ".NET Coverage" in .NET and NUnit runners, but also by using a standalone dotCover runner.

DotCover Runner Settings

This runner allows you to:

  • Launch any process under the dotCover coverage profile and generate its own snapshots.

  • Merge snapshots generated by preceding steps to produce a consolidated report displayed on the Code Coverage Tab.

Learn more: dotCover.

Bundled dotCover Versions

TeamCity Version

dotCover Version

2018.1

2018.1.2

2018.2

2018.1.4

2019.1

2019.1.1

2019.2

2019.2.3

2020.1

2019.2.3

2020.2

2020.2.4

2021.1

2021.1.2

2021.2 ~ 2023.05

2021.2.2

2023.11

2023.2.2

2024.03 and newer

2023.3.3

You can view the installed versions of dotCover on the Server Administration | Tools page. The bundled version is set as default, you can install other versions and change the default settings.

note

The dotCover console tool supports profiling of .NETCore.App 2.0+ since version 2019.2.

Cross-platform dotCover

TeamCity allows collecting coverage for .NET Core projects on Linux and macOS by supporting cross-platform JetBrains dotCover, version 2019.2.3+.

dotCover 2019.2.3 for Windows is bundled with TeamCity. If you need to collect code coverage under non-Windows platforms, install the cross-platform dotCover tool on a build engine and enable the dotCover coverage in the .NET build step. If you want to use cross-platform dotCover under Windows as well, make sure the agents have .NET Framework SDK 4.6.1+ installed.

note

For Linux and macOS agents, all additional dotCover arguments must be preceded with -- characters. For example, the /LogFile parameter is used to enable the main log on Windows; on Linux and macOS, --LogFile must be used instead.

You can also run dotCover code coverage analysis inside a container, with the Container Wrapper extension.

See also

Administrator's Guide

Troubleshooting