The character set to use for the step's output. If not specified, the charset associated with the build will be used.

Defines the build configuration. The default for most projects is Debug, but you can override the build configuration settings in your project.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Forces all dependencies to be resolved even if the last restore was successful. Specifying this flag is the same as deleting the project.assets.json file.

Compiles for a specific framework. The framework must be defined in the project file.

Ignores project-to-project references and only restores the root project.

Marks the build as unsafe for incremental build. This flag turns off incremental compilation and forces a clean rebuild of the project's dependency graph.

Doesn't execute an implicit restore when running the command.

Doesn't display the startup banner or the copyright message.

Available since: .NET Core SDK 3.0

For more information about these options, see the MSBuild Command-Line Reference.

If targets and/or properties are also configured, those will be passed after these options.

Directory in which to place the built binaries. If not specified, the default path is ./bin/<configuration>/<framework>/. For projects with multiple target frameworks (via the TargetFrameworks property), you also need to specify a specific framework when you specify this option.

The MSBuild project or solution to build. If a directory is specified, MSBuild searches it for a (single) file that has a file extension that ends in proj or sln, and uses that file. If nothing is specified, the current working directory is searched in the same way.

Additional MSBuild properties to set. These should be specified one per line, in Java properties syntax.

Specifies the target runtime. For a list of Runtime Identifiers (RIDs), see the RID catalog.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

If enabled, dotnet build-server shutdown will be executed after the main command, shutting down build servers that may have been started.

Note: If this is not specified, a build that causes such a build server to be started may hang until those server processes end. As such, it's recommended to specify this for the last .NET-related step in a job. If using multiple SDKs, each needs its own shutdown (e.g. the .NET Core 3.1 SDK will not shut down build servers from the .NET 5.0 SDK).

Available since: .NET Core SDK 2.1

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

Specifies the MSBuild targets to build. If none are specified, the default target specified in the project will be built.

If this is set and the build completes with errors, the build will be marked as unstable instead of failed, and execution will continue to the next step.

If this is set and the build completes with warnings (but no errors), the build will be marked as unstable instead of successful.

Sets the MSBuild verbosity level.

Sets the value of the $(VersionSuffix) property to use when building the project. This only works if the $(Version) property isn't set. Then, $(Version) is set to the $(VersionPrefix) combined with the $(VersionSuffix), separated by a dash.

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

Defines the build configuration. The default for most projects is Debug, but you can override the build configuration settings in your project. This option is only required when cleaning if you specified it during build time.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

The framework that was specified at build time. The framework must be defined in the project file. If you specified the framework at build time, you must specify the framework when cleaning.

Doesn't display the startup banner or the copyright message.

Available since: .NET Core SDK 3.0

For more information about these options, see the MSBuild Command-Line Reference.

If targets and/or properties are also configured, those will be passed after these options.

The directory that contains the build artifacts to clean. If you specified the framework when the project was built, that same framework should also be specified for this cleanup action.

The MSBuild project or solution to clean. If a directory is specified, MSBuild searches it for a (single) file that has a file extension that ends in proj or sln, and uses that file. If nothing is specified, the current working directory is searched in the same way.

Additional MSBuild properties to set. These should be specified one per line, in Java properties syntax.

Cleans the output folder of the specified runtime. This is used when a self-contained deployment was created.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

If enabled, dotnet build-server shutdown will be executed after the main command, shutting down build servers that may have been started.

Note: If this is not specified, a build that causes such a build server to be started may hang until those server processes end. As such, it's recommended to specify this for the last .NET-related step in a job. If using multiple SDKs, each needs its own shutdown (e.g. the .NET Core 3.1 SDK will not shut down build servers from the .NET 5.0 SDK).

Available since: .NET Core SDK 2.1

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

If this is set and the build completes with errors, the build will be marked as unstable instead of failed, and execution will continue to the next step.

If this is set and the build completes with warnings (but no errors), the build will be marked as unstable instead of successful.

Sets the MSBuild verbosity level.

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

The API key for the server.

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Forces the application to run using an invariant, English-based culture.

Doesn't append "api/v2/package" to the source URL.

Available since: .NET Core SDK 2.1

Name/ID of the package to delete.

Version of the package to delete.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

Specifies the server URL. Supported URLs for nuget.org include https://www.nuget.org, https://www.nuget.org/api/v3, and https://www.nuget.org/api/v2/package. For private feeds, replace the host name (for example, %hostname%/api/v3).

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

Configuration file containing the NuGet sources to use when searching for newer packages. Requires the --outdated, --deprecated or --vulnerable option.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Lists packages that have been deprecated. Cannot be combined with --vulnerable or --outdated options.

Available since: .NET Core SDK 3.1.300

Displays only the packages applicable for the specified target frameworks.

Considers only the packages with a matching major version number when searching for newer packages. Requires the --outdated option.

Considers only the packages with a matching major and minor version numbers when searching for newer packages. Requires the --outdated option.

Considers packages with prerelease versions when searching for newer packages. Requires the --outdated option.

Lists transitive packages, in addition to the top-level packages. When specifying this option, you get a list of packages that the top-level packages depend on.

Lists packages that have newer versions. Cannot be combined with --deprecated or --vulnerable options.

The project or solution file to operate on. If not specified, the command searches the current directory for one. If more than one solution or project is found, an error is thrown.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

The NuGet sources to use when searching for packages. Requires the --outdated>, --deprecated> or --vulnerable> option.

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

Sets the verbosity level of the command.

Note that this option only has an effect since the .NET 5 SDK.

Lists packages that have known vulnerabilities. Cannot be combined with --deprecated or --outdated options.

Available since: .NET Core SDK 5.0.200

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

The cache location to list or clear. It accepts one of the following values:

• all: Indicates that the specified operation is applied to all cache types: http-request cache, global packages cache, and the temporary cache.
• global-packages: Indicates that the specified operation is applied only to the global packages cache. The other cache locations aren't affected.
• http-cache: Indicates that the specified operation is applied only to the http-request cache. The other cache locations aren't affected.
• temp: Indicates that the specified operation is applied only to the temporary cache. The other cache locations aren't affected.

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Forces the application to run using an invariant, English-based culture.

Two operations are supported:

• clear: The contents of the cache directories are deleted recursively. The executing user/group must have permission to the files in the cache directories. If not, an error is displayed indicating the files/folders that weren't cleared.
• list: Displays the path to the specified cache location.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

Defines the build configuration. The default for most projects is Debug, but you can override the build configuration settings in your project.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Forces all dependencies to be resolved even if the last restore was successful. Specifying this flag is the same as deleting the project.assets.json file.

Includes the debug symbols NuGet packages in addition to the regular NuGet packages in the output directory. The sources files are included in the src folder within the symbols package.

Includes the debug symbols NuGet packages in addition to the regular NuGet packages in the output directory.

Doesn't build the project before packing, and does not perform an implicit restore.

Ignores project-to-project references and only restores the root project.

Doesn't execute an implicit restore when running the command.

Doesn't display the startup banner or the copyright message.

Available since: .NET Core SDK 3.0

For more information about these options, see the MSBuild Command-Line Reference.

If targets and/or properties are also configured, those will be passed after these options.

Places the built packages in the directory specified.

The project or solution to pack. It's either a path to a csproj file, vbproj file, fsproj file, a solution file, or to a directory. If not specified, the command searches the current directory for a project or solution file.

Additional MSBuild properties to set. These should be specified one per line, in Java properties syntax.

Specifies the target runtime to restore packages for. For a list of Runtime Identifiers (RIDs), see the RID catalog.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

If enabled, dotnet build-server shutdown will be executed after the main command, shutting down build servers that may have been started.

Note: If this is not specified, a build that causes such a build server to be started may hang until those server processes end. As such, it's recommended to specify this for the last .NET-related step in a job. If using multiple SDKs, each needs its own shutdown (e.g. the .NET Core 3.1 SDK will not shut down build servers from the .NET 5.0 SDK).

Available since: .NET Core SDK 2.1

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

If this is set and the build completes with errors, the build will be marked as unstable instead of failed, and execution will continue to the next step.

If this is set and the build completes with warnings (but no errors), the build will be marked as unstable instead of successful.

Sets the MSBuild verbosity level.

Defines the value for the $(VersionSuffix) MSBuild property in the project.

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

Defines the build configuration. The default for most projects is Debug, but you can override the build configuration settings in your project.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Forces all dependencies to be resolved even if the last restore was successful. Specifying this flag is the same as deleting the project.assets.json file.

Publishes the application for the specified target framework. You must specify the target framework in the project file.

Specifies one or several target manifests to use to trim the set of packages published with the app. The manifest file is part of the output of the dotnet store command.

Doesn't build the project before publishing, and does not perform an implicit restore.

Ignores project-to-project references and only restores the root project.

Doesn't execute an implicit restore when running the command.

Doesn't display the startup banner or the copyright message.

Available since: .NET Core SDK 3.0

For more information about these options, see the MSBuild Command-Line Reference.

If targets and/or properties are also configured, those will be passed after these options.

Specifies the path for the output directory.
If not specified, it defaults to [project_file_folder]./bin/[configuration]/[framework]/publish/ for a runtime-dependent executable and cross-platform binaries. It defaults to [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ for a self-contained executable.
In a web project, if the output folder is in the project folder, successive dotnet publish commands result in nested output folders. For example, if the project folder is myproject, and the publish output folder is myproject/publish, and you run dotnet publish twice, the second run puts content files such as .config and .json files in myproject/publish/publish. To avoid nesting publish folders, specify a publish folder that is not directly under the project folder, or exclude the publish folder from the project.

Some behaviour depends on the SDK version:

• .NET Core 3.x SDK and later: If a relative path is specified when publishing a project, the output directory generated is relative to the current working directory, not to the project file location.
  If a relative path is specified when publishing a solution, all output for all projects goes into the specified folder relative to the current working directory. To make publish output go to separate folders for each project, specify a relative path by using the msbuild PublishDir property instead of this option.
• .NET Core 2.x SDK: If a relative path is specified when publishing a project, the output directory generated is relative to the project file location, not to the current working directory.
  If a relative path is specified when publishing a solution, each project's output goes into a separate folder relative to the project file location. If an absolute path is specified when publishing a solution, all publish output for all projects goes into the specified folder.

The project or solution (or directory containing a project or solution) to publish. If not specified, the current directory is used.
Note that the use of a solution instead of a project was added in the .NET Core 3.0 SDK.

Additional MSBuild properties to set. These should be specified one per line, in Java properties syntax .

Properties of particular interest to dotnet publish:

• PublishProfile=Properties\PublishProfiles\profile.pubxml: Use a .pubxml to set publish-related properties. See Visual Studio publish profiles (.pubxml) for ASP.NET Core app deployment for more information.
• PublishReadyToRun=true: Compiles application assemblies as ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation. For more information, see ReadyToRun images.
  Available since .NET Core 3.0 SDK.
• PublishSingleFile=true: Packages the app into a platform-specific single-file executable. The executable is self-extracting and contains all dependencies (including native) that are required to run the app. When the app is first run, the application is extracted to a directory based on the app name and build identifier. Startup is faster when the application is run again. The application doesn't need to extract itself a second time unless a new version is used.
  For more information about single-file publishing, see the single-file bundler design document .
  Available since .NET Core 3.0 SDK.
• PublishTrimmed=true: Trims unused libraries to reduce the deployment size of an app when publishing a self-contained executable. For more information, see Trim self-contained deployments and executables .
  Available since .NET Core 3.0 SDK.

Note that it is recommended to specify all of these, other than PublishProfile, in a publish profile rather than here.

Publishes the application for a given runtime. For a list of Runtime Identifiers (RIDs), see the RID catalog. For more information, see .NET Core application publishing and Publish .NET Core apps with the .NET Core CLI.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

Publishes the .NET Core runtime with your application so the runtime doesn't need to be installed on the target machine. Enabled by default if a runtime identifier is specified and the project is an executable project (not a library project). For more information, see .NET Core application publishing and Publish .NET Core apps with the .NET Core CLI.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

If enabled, dotnet build-server shutdown will be executed after the main command, shutting down build servers that may have been started.

Note: If this is not specified, a build that causes such a build server to be started may hang until those server processes end. As such, it's recommended to specify this for the last .NET-related step in a job. If using multiple SDKs, each needs its own shutdown (e.g. the .NET Core 3.1 SDK will not shut down build servers from the .NET 5.0 SDK).

Available since: .NET Core SDK 2.1

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

If this is set and the build completes with errors, the build will be marked as unstable instead of failed, and execution will continue to the next step.

If this is set and the build completes with warnings (but no errors), the build will be marked as unstable instead of successful.

Sets the MSBuild verbosity level.

Defines the version suffix to replace the asterisk (*) in the version field of the project file.

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

The API key for the server.

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Disables buffering when pushing to an HTTP(S) server to reduce memory usage.

Forces the application to run using an invariant, English-based culture.

Doesn't append "api/v2/package" to the source URL.

Available since: .NET Core SDK 2.1

Doesn't push symbols (even if present).

Specifies the file path to the package(s) to be pushed.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

When pushing multiple packages to an HTTP(S) server, treats any 409 Conflict response as a warning so that the push can continue.

Available since: .NET Core SDK 3.1

Specifies the server URL. Supported URLs for nuget.org include https://www.nuget.org, https://www.nuget.org/api/v3, and https://www.nuget.org/api/v2/package. For private feeds, replace the host name (for example, %hostname%/api/v3).
This option is required unless DefaultPushSource config value is set in the NuGet config file.

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

The API key for the symbol server.

Specifies the symbol server URL.

Specifies the timeout for pushing to a server in seconds. Defaults to 300 seconds (5 minutes). Specifying 0 (zero seconds) applies the default value.

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

Runs the tests in blame mode. This option is helpful in isolating problematic tests that cause the test host to crash. When a crash is detected, it creates an sequence file in TestResults/<Guid>/<Guid>_Sequence.xml that captures the order of tests that were run before the crash.

Runs the tests in blame mode and collects a crash dump when the test host exits unexpectedly. This option depends on the version of .NET used, the type of error, and the operating system.
For exceptions in managed code, a dump will be automatically collected on .NET 5.0 and later versions. It will generate a dump for the test host or any child process that also ran on .NET 5.0 and crashed. Crashes in native code will not generate a dump. This option works on Windows, macOS, and Linux.
Crash dumps in native code, or when using .NET Core 3.1 or earlier versions, can only be collected on Windows, by using Procdump. A directory that contains procdump.exe and procdump64.exe must be in the PATH or PROCDUMP_PATH environment variable. Download the tools. Implies --blame.
To collect a crash dump from a native application running on .NET 5.0 or later, the usage of Procdump can be forced by setting the VSTEST_DUMP_FORCEPROCDUMP environment variable to 1.

Available since: .NET 5.0 preview SDK

Collects a crash dump on expected as well as unexpected test host exit.

Available since: .NET 5.0 preview SDK

The type of crash dump to be collected. Implies --blame-crash.

Available since: .NET 5.0 preview SDK

Run the tests in blame mode and collects a hang dump when a test exceeds the given timeout.

Available since: .NET 5.0 preview SDK

The type of crash dump to be collected. It should be full, mini, or none. When none is specified, the test host is terminated on timeout, but no dump is collected. Implies --blame-hang.

Available since: .NET 5.0 preview SDK

Per-test timeout, in milliseconds, after which a hang dump is triggered and the test host process and all of its child processes are dumped and terminated.
When used together with data driven tests, the timeout behavior depends on the test adapter used. For xUnit and NUnit the timeout is renewed after every test case. For MSTest, the timeout is used for all test cases. This option is supported on Windows with netcoreapp2.1 and later, on Linux with netcoreapp3.1 and later, and on macOS with net5.0 or later. Implies --blame and --blame-hang.

Available since: .NET 5.0 preview SDK

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

Enables a data collector for the test run. For more information, see Monitor and analyze test run.

Defines the build configuration. The default for most projects is Debug, but you can override the build configuration settings in your project.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Enables diagnostic mode for the test platform and writes diagnostic messages to the specified file and to files next to it. The process that is logging the messages determines which files are created, such as *.host_<date>.txt for the test host log, and *.datacollector_<date>.txt for the data collector log.

Filters out tests in the current project using the given expression. For more information, see the Filter option details section. For more information and examples on how to use selective unit test filtering, see Running selective unit tests.

Forces the use of dotnet or a .NET Framework test host for the test binaries. This option only determines which type of host to use. The actual framework version to be used is determined by the runtimeconfig.json of the test project. When not specified, the TargetFramework assembly attribute is used to determine the type of host. When that attribute is stripped from the .dll, the .NET Framework host is used.

List all of the discovered tests in the current project.

Specifies a logger for test results. Unlike MSBuild, dotnet test doesn't accept abbreviations: instead of "console;v=d", use "console;verbosity=detailed".

Doesn't build the project before packing, and does not perform an implicit restore.

Doesn't execute an implicit restore when running the command.

Doesn't display the startup banner or the copyright message.

Available since: .NET Core SDK 3.0

For more information about these options, see the MSBuild Command-Line Reference.

If targets and/or properties are also configured, those will be passed after these options.

Directory in which to find the binaries to run. If not specified, the default path is ./bin/<configuration>/<framework>/. For projects with multiple target frameworks (via the TargetFrameworks property), you also need to specify a framework when you specify this option. dotnet test always runs tests from the output directory. You can use AppDomain.BaseDirectory to consume test assets in the output directory.

What to test. This can be one of:

• Path to a test project.
• Path to a solution.
• Path to a directory that contains a project or a solution.
• Path to a test project .dll file.

If not specified, it searches for a project or a solution in the current directory.

Additional MSBuild properties to set. These should be specified one per line, in Java properties syntax.

The directory where the test results are going to be placed. If the specified directory doesn't exist, it's created. The default is TestResults in the directory that contains the project file.

Inline RunSettings values, specified in in Java properties syntax.

The target runtime to test for.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

The .runsettings file to use for running the tests. Note that the TargetPlatform element (x86|x64) has no effect for dotnet test. To run tests that target x86, install the x86 version of .NET Core. The bitness of the dotnet.exe that is on the path is what will be used for running tests.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

If enabled, dotnet build-server shutdown will be executed after the main command, shutting down build servers that may have been started.

Note: If this is not specified, a build that causes such a build server to be started may hang until those server processes end. As such, it's recommended to specify this for the last .NET-related step in a job. If using multiple SDKs, each needs its own shutdown (e.g. the .NET Core 3.1 SDK will not shut down build servers from the .NET 5.0 SDK).

Available since: .NET Core SDK 2.1

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

Path to a directory to be searched for additional test adapters. Only .dll files with suffix .TestAdapter.dll are inspected. If not specified, the directory of the test .dll is searched.

If this is set and the build completes with errors, the build will be marked as unstable instead of failed, and execution will continue to the next step.

If this is set and the build completes with warnings (but no errors), the build will be marked as unstable instead of successful.

Sets the MSBuild verbosity level.

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

The NuGet configuration file (nuget.config) to use for the restore operation.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Disables restoring multiple projects in parallel.

Forces all dependencies to be resolved even if the last restore was successful. Specifying this flag is the same as deleting the project.assets.json file.

Forces restore to reevaluate all dependencies even if a lock file already exists.

Only warn about failed sources if there are packages meeting the version requirement.

Output location where project lock file is written. By default, this is PROJECT_ROOT\packages.lock.json.

Don't allow updating project lock file.

Specifies to not cache HTTP requests.

When restoring a project with project-to-project (P2P) references, restores the root project and not the references.

Specifies the directory for restored packages.

Optional path to the project file to restore.

Specifies runtimes for the package restore. This is used to restore packages for runtimes not explicitly listed in the <RuntimeIdentifiers> tag in the .csproj file. For a list of Runtime Identifiers (RIDs), see the RID catalog.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

Specifies NuGet package sources to use during the restore operation. This setting overrides all of the sources specified in the nuget.config files.

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

Enables the project lock file to be generated and used with restore.

Sets the verbosity level of the command.

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

Adds additional NuGet package sources to use during installation.

The character set to use for the step's output. If not specified, the charset associated with the build will be used.

The NuGet configuration (nuget.config) file to use.

If this is checked, errors encountered will cause the build status to be set to FAILURE (or UNSTABLE, if configured that way), but the build will be allowed to continue. Otherwise, any such errors will cause the build to be terminated immediately.

Prevent restoring multiple projects in parallel.

Treat package source failures as warnings.

Do not cache packages and http requests.

Name of a .NET SDK to use so that dotnet will be in the path.
If the default is specified, you either need to use the With .NET element (or a withDotNet block in a pipeline script) to specify one, or ensure this step runs on a node that has a .NET SDK installed and in the path.

If enabled, dotnet --info will be executed before the main command. This shows a list of available SDKs and runtimes, indicating which one is currently being used.

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.

Path to the manifest file.

Sets the verbosity level of the command. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic].

The directory in which to execute the command. By default, this is the current directory (for freestyle jobs, that is the root of the job's workspace).

Name of a .NET SDK to use so that dotnet will be in the path.

Depending on the platform, the dotnet executable may use the most recent SDK available on the system, even when PATH is set up to find an older SDK deployment first; see this page for more information.
By enabling this option, the configured SDK home directory will be checked, and if it only includes a single SDK deployment, a global.json file will be created in the current directory, referencing that SDK version and disabling roll-forward.

Note: This will silently overwrite any global.json already present in the current directory.