.NET

.NET Version Detection Algorithm

TeamCity searches for the .NET executable files in the following order:

1. In the directory defined in the environment variable DOTNET_HOME for a TeamCity agent. For example, DOTNET_HOME=D:\SDK\dotnet\.

2. In the default directory for the .NET executable file:

   • Windows: C:\Program Files\dotnet or C:\Program Files (x86)\dotnet, or other default program files directory (depending on the environment variable ProgramW6432)

   • Unix: /usr/share/dotnet

   • Mac: /usr/local/share/dotnet

3. In paths specified in the PATH environment variable.

TeamCity will use the first .NET version it finds. If you have several .NET versions installed, we recommend that you specify the most recent version in the DOTNET_HOME variable.

Main Settings

Command

Allows you to choose one of the following commands:

• build

• clean

• restore
  (requires .NET CLI 2.1.400+ for authentication in private feeds)

• pack

• publish

• run

• test

• msbuild

• vstest

• nuget delete
  (requires .NET CLI 2.1.500+ for authentication in private feeds)

• nuget push
  (requires .NET CLI 2.1.500+ for authentication in private feeds)

• devenv (read more in the Visual Studio reference)

• custom .NET commands

Projects

The newline-separated list of paths to projects and solutions. Supports * wildcards are supported. Does not support parameter references.

Working directory

The directory where the build step starts. By default, this is the same root directory where the agent checks out remote sources. See this topic for more information: Build Working Directory.

Framework

Target framework. For example, netcoreapp or netstandard. Supports parameter references.

Required SDK

A space-separated list of SDKs that must be installed on a build agent. For example, For example, 8 4.8.2.

Agents without these are labeled as incompatible to run this build.

Configuration

Target configuration. For example, Release or Debug. Supports parameter references.

Runtime

Target runtime. Supports parameter references.

If the specified project file mentions any runtime ID, you can quickly select this runtime by clicking the button.

Options

Additional options available for certain commands.

• Do not build the projects — allows you to publish or test projects without building them first.

• Run tests in a single session — allows TeamCity to invoke a separate testing command for each target when multiple test assemblies are listed as targets for a test or vstest command.

NuGet package sources

NuGet package sources to use during restoring.

Output directory

The directory where to place outputs. Supports prameter references.

Version suffix

The value of the $(VersionSuffix) property in the project. Supports parameter references.

Command line parameters

Additional command line parameters for the dotnet command.

Logging verbosity

Allows you to choose one of the following logging verbosity modes:

• <Default>

• Minimal

• Normal

• Detailed

• Diagnostic

'msbuild' Command Options

The msbuild command is used for building a project and all its dependencies with the Microsoft Build Engine. Depending on the selected MSBuild version, msbuild can either be run as the cross-platform .NET CLI command or as the Windows-only msbuild.exe tool.

The msbuild command shares some of the common options with the basic CLI commands of the .NET runner (see the corresponding section for more details).

Supported MSBuild versions: 4 or later / 12 or later.

Targets

The list of targets separated by a space or semicolon. A target is an arbitrary script for your project purposes. Click the list icon next to the field to view available targets.

MSBuild version

The version of the installed MSBuild engine. To ensure that a specific version of native MSBuild is used (for example, in a Docker container), you need to set the path to MSBuild.exe in the PATH environment variable. See the Agent Requirements section for more details.

If you set the version in this field and choose to run the current step inside a container, make sure to specify the path to MSBuild.exe in the PATH environment variable. This way, the .NET runner will be able to find the required executable file even within the Docker container.

'vstest' Command Options

The vstest command is used for testing a project with the VSTest engine and automatically importing the test results. Depending on the selected VSTest version, vstest can either be run as the cross-platform .NET CLI command or as the VSTest console.

Supported VSTest versions: 2013 or later.

Test assemblies

The newline-separated list of paths (relative to the build checkout directory) to assemblies to run tests on. Supports wildcards.

Excluded test assemblies

The new-line separated list of paths (relative to the build checkout directory) to assemblies that the vstest command should ignore. Supports wildcards.

VSTest version

The version of VSTest to use. See the Agent Requirements section for more information.

Platform

The target platform. For example, x86, x64, or ARM. Leave <Auto> to let VSTest select the platform automatically.

Run in isolation

Allows TeamCity to run the tests in an isolated process.

Test filtration

Allows you to select on of the following test filtration modes:

• Test names — Of all tests discovered in the included assemblies, only the tests with the names matching the provided values will be run. For multiple values, separate them with a new line. If the field is empty, all tests will be run. See details in the Microsoft documentation.

• Test case filter — Run tests that match the given expression. See details in the Microsoft documentation.

See also: Run selected unit tests

Test retry count

In the event of a test failure, TeamCity can seamlessly initiate automated re-runs of said test during the same build run. Failed tests are re-launched until they either achieve success or exhaust the maximum number of attempts. This technique allows you to identify flaky tests and distinguish them from genuinely problematic tests that consistently fail regardless of the number of launch attempts.

Tests that initially failed but managed to finish successfully during subsequent re-runs are automatically muted. You can check the Tests tab of a build results page to see how many re-runs were required for each test.

Settings file

The path to the .runsettings file.

'devenv' Command Options

The .NET runner supports the Visual Studio command-line mode with the devenv command.

Devenv allows configuring custom options for the IDE, build, debug, and deploy projects from the command line using different switches.

devenv shares some of the common options with the basic CLI commands of the .NET runner (see the corresponding section for more details).

Build action

One of the supported values:

• clean

• rebuild

• build

• deploy

Visual Studio version

The version of the installed Visual Studio. Leave <Any> to use the latest installed version.

See the Agent Requirements section for more details.

Container Settings

This build step can run inside a container deployed by Docker or Podman.

Classic build configuration steps display a set of properties that allow you to specify the image name, platform, and additional run arguments. The Pull image explicitly ensures TeamCity pulls an image from the target container every time this step runs.

To point TeamCity to a registry where it should look for the specified image, add Docker/Podman connection to your project. By default, this connection allows TeamCity to pull images from Docker Hub in anonymous mode, but you can set it up for any container registry.

See the following article for more information: Container Wrapper.

Toggle Run in Docker on to run a step inside a container. When enabled, this element displays two options.

• Docker image — allows you to pull an image from a Docker or Podman registry. By default, TeamCity can pull Docker Hub images in anonymous mode. For other cases (private images, custom image registries, non-anonymous mode that ensures you do not violate Docker Hub rate limits), configure a Docker integration on a pipeline or job level.

• Dockerfile — allows you to build a custom image from a Dockerfile.

Code Coverage

JetBrains dotCover is supported as a coverage tool for msbuild, test, vstest, and a number of custom commands. To merge snapshots produced by multiple individual .NET runners into one consolidated report, add the dotCover to your configuration.

Migrating from Deprecated Runners to .NET Runner

Migrating from MSBuild Runner

Since TeamCity 2019.2.3, the .NET runner is the recommended method for building projects with the MSBuild engine. We have included the msbuild command to our refactored .NET runner to ensure long-term support of the .NET platform development strategy.

You can safely switch MSBuild steps in your existing build configurations to the .NET runner. Make sure to copy all additional command-line parameters and other important settings to the new runner. See the msbuild section for more details on the settings available in the .NET runner.

Additional features you will get in the .NET runner are:

• Support of cross-platform MSBuild for .NET projects.

• Ability to build a project for a different platform specified in the Runtime field.

• Ability to run the project in a Docker container with our Container Wrapper extension.

Consider the following notes before migrating:

• The .NET runner uses x86 run platform by default. If the x86 version is not available, it will use x64.

• The .NET runner provides code coverage only for dotCover.

• Mono is not supported with this runner.

If you are actively using either Mono or NCover/PartCover in your MSBuild steps, please let us know about it via any of the feedback channels.

Migrating from Visual Studio (sln) Runner

The Visual Studio (sln) build runner is using the MSBuild engine under its hood and provides a few tweaks for the VS users to ease their experience with building projects in TeamCity. Since TeamCity 2019.2.3, the .NET runner is the recommended method for building projects with the MSBuild engine which makes it a migration option for the users of the Visual Studio (sln) step as well.

In general, to softly switch each existing Visual Studio (sln) build step to the .NET runner you need to:

1. Remember/copy the values of your Visual Studio (sln) runner's settings and command-line parameters.

2. Switch the Visual Studio (sln) build step to the .NET runner and select the msbuild command.

3. Fill in the fields according to the msbuild section.
   Note that certain fields have different analogs in the .NET runner:

   • The MSBuild version should be specified instead of the version and platform of Visual Studio. See the reference on versions.

   • Paths to solutions should be specified in the Projects field.

Refer to the respective section for more information on migration to msbuild.

Migrating from Visual Studio Tests Runner

Since TeamCity 2019.2.3, the .NET runner is the recommended method for testing projects with VSTest instead of the Visual Studio Tests runner. We have included the vstest command to our refactored .NET runner to ensure a long-term support of the .NET platform development strategy.

You can safely migrate existing Visual Studio Tests build steps to the .NET runner with the selected vstest command. Make sure to copy all additional command-line parameters and other important settings to the new runner. See the vstest section for more details on the settings available in the .NET runner.

Additional features you will get in the .NET runner are:

• Support of cross-platform VSTest for .NET projects.

• Real-time test reporting by default.

• Support of ARM platform, along with x86 and x64.

• Ability to run and test the project inside a Docker container with our Container Wrapper extension.

Consider the following notes before migrating:

• The .NET runner supports the new .runsettings format of the VSTest settings file. However, it does not support the obsolete run configuration file format used in the Visual Studio Tests runner.

• Instead of the framework version, the .NET runner requests to specify the VSTest version.

• The .NET runner provides code coverage only for dotCover. If you are actively using NCover or PartCover in your MSBuild steps, please let us know about it via any of the feedback channels.

• The .NET runner does not support the MSTest tool since all features of its framework are covered by VSTest. If you were using MSTest as the engine of the Visual Studio Tests runner, we suggest that you switch to VSTest when migrating to the .NET runner.

How to pass parameters containing spaces

The best way to pass a parameter value containing space characters is to use system properties. For example, you can add the system.Platform parameter with the Any CPU value in Build Configuration Settings | Parameters and then refer to this value as %system.Platform% inside the .NET step.

An alternative approach is to wrap the command-line parameter as follows: "/p:Platform=Any CPU".