|
1 | 1 | --- |
2 | 2 | title: VSTest.Console.exe command-line options |
3 | 3 | description: Learn about the VSTest.Console.exe command-line tool that runs tests. This article includes the General command-line options. |
4 | | -ms.date: 07/13/2026 |
| 4 | +ms.date: 07/17/2026 |
5 | 5 | ms.topic: reference |
6 | 6 | helpviewer_keywords: |
7 | 7 | - vstest.console.exe |
@@ -37,21 +37,23 @@ The following table lists all the options for *VSTest.Console.exe* and short des |
37 | 37 | |**/UseVsixExtensions**|This option makes the *vstest.console.exe* process use or skip the VSIX extensions installed (if any) in the test run.<br />This option is deprecated. Starting from the next major release of Visual Studio this option may be removed. Move to consuming extensions made available as a NuGet package.<br />Example: `/UseVsixExtensions:true`| |
38 | 38 | |**/TestAdapterPath:[*path*]**|Forces the *vstest.console.exe* process to use custom test adapters from a specified path (if any) in the test run.<br />Example: `/TestAdapterPath:[pathToCustomAdapters]`| |
39 | 39 | |**/Platform:[*platform type*]**|Forces the given platform to be used, instead of the platform determined from the current runtime. This option is able to force only x86, and x64 platforms on Windows. The ARM option is broken and will result in x64 on most systems.<br />Do NOT specify this option to run on runtimes that aren't in the list of valid values such as ARM64.<br />Valid values are x86, x64, and ARM.<br /> |
40 | | -|**/Framework: [*framework version*]**|Target .NET version to be used for test execution.<br />Example values are `Framework35`, `Framework40`, `Framework45`, `FrameworkUap10`, `.NETCoreApp,Version=v1.1`.<br />TargetFrameworkAttribute is used to automatically detect this option from your assembly, and defaults to `Framework40` when the attribute isn't present. You must specify this option explicitly if you remove the [TargetFrameworkAttribute](/dotnet/api/system.runtime.versioning.targetframeworkattribute) from your .NET Core assemblies.<br />If the target framework is specified as **Framework35**, the tests run in CLR 4.0 "compatibility mode".<br />Example: `/Framework:framework40`| |
41 | | -|**/TestCaseFilter:[*expression*]**|Run tests that match the given expression.<br /><Expression\> is of the format <property\>=<value\>[\|<Expression\>].<br />Example: `/TestCaseFilter:"Priority=1"`<br />Example: `/TestCaseFilter:"TestCategory=Nightly|FullyQualifiedName=Namespace.ClassName.MethodName"`<br />The **/TestCaseFilter** command-line option can't be used with the **/Tests** command-line option. <br />For information about creating and using expressions, see [TestCase filter](https://github.com/microsoft/vstest/blob/main/docs/filter.md).| |
| 40 | +|**/Framework: [*framework version*]**|Target .NET version to be used for test execution.<br />Modern framework short forms are accepted and parsed by the NuGet framework parser, for example `net48`, `net6.0`, or `net10.0` (as well as the long forms such as `.NETFramework,Version=v4.8` and `.NETCoreApp,Version=v10.0`).<br />The legacy aliases `Framework35`, `Framework40`, `Framework45`, `FrameworkCore10`, and `FrameworkUap10` are also accepted.<br />TargetFrameworkAttribute is used to automatically detect this option from your assembly, and defaults to `Framework40` when the attribute isn't present. You must specify this option explicitly if you remove the [TargetFrameworkAttribute](/dotnet/api/system.runtime.versioning.targetframeworkattribute) from your .NET Core assemblies.<br />If the target framework is specified as **Framework35**, the tests run in CLR 4.0 "compatibility mode".<br />Example: `/Framework:net8.0`| |
| 41 | +|**/TestCaseFilter:[*expression*]**|Run tests that match the given expression.<br /><Expression\> is of the format <property\>=<value\>[\|<Expression\>].<br />Example: `/TestCaseFilter:"Priority=1"`<br />Example: `/TestCaseFilter:"TestCategory=Nightly|FullyQualifiedName=Namespace.ClassName.MethodName"`<br />The **/TestCaseFilter** command-line option can't be used with the **/Tests** command-line option. <br />For information about creating and using expressions, see [TestCase filter](https://github.com/microsoft/vstest/blob/main/docs/filter.md). When you type a filter directly in a shell, see [Escape filter expressions in the shell](#escape-filter-expressions-in-the-shell).| |
| 42 | +|**/Environment:[*NAME*]=[*VALUE*]**|Sets the value of an environment variable for the test host process. Creates the variable if it doesn't exist, and overrides it if it does. This option implies **/InIsolation** and forces the tests to run in an isolated process. Specify the option multiple times to set multiple variables. Short form: **/e**.<br />Example: `/e:VARIABLE1=VALUE1`| |
42 | 43 | |**/?**|Displays usage information.| |
43 | | -|**/Logger:[*uri/friendlyname*]**|Specify a logger for test results. Specify the parameter multiple times to enable multiple loggers.<br />Example: To log results into a Visual Studio Test Results File (TRX), use<br />**/Logger:trx**<br />**[;LogFileName=\<Defaults to unique file name>]**<br />For more information, see [Logging example](#logging-example).| |
44 | | -|**/ListTests:[*file name*]**|Lists discovered tests from the given test container.<br />Note: The `/TestCaseFilters` option has no effect when listing tests; it only controls which tests get run.| |
| 44 | +|**/Logger:[*uri/friendlyname*]**|Specify a logger for test results. Specify the parameter multiple times to enable multiple loggers.<br />Example: To log results into a Visual Studio Test Results File (TRX), use<br />**/Logger:trx**<br />**[;LogFileName=\<Defaults to unique file name>]**<br />Use `LogFilePrefix=<prefix>` instead of `LogFileName` to keep a separate, timestamped file per run. `LogFileName` sets an explicit name and overwrites the previous file, whereas `LogFilePrefix` doesn't.<br />For more information, see [Logging example](#logging-example).| |
| 45 | +|**/ListTests:[*file name*]**|Lists discovered tests from the given test container. Short form: **/lt**.<br />Note: The `/TestCaseFilters` option has no effect when listing tests; it only controls which tests get run.| |
45 | 46 | |**/ListDiscoverers**|Lists installed test discoverers.| |
46 | 47 | |**/ListExecutors**|Lists installed test executors.| |
47 | 48 | |**/ListLoggers**|Lists installed test loggers.| |
48 | 49 | |**/ListSettingsProviders**|Lists installed test settings providers.| |
49 | | -|**/Blame**|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 a sequence file in `TestResults/<Guid>/<Guid>_Sequence.xml` that captures the order of tests that were run before the crash. For more information, see [Blame data collector](https://github.com/microsoft/vstest/blob/main/docs/extensions/blame-datacollector.md).| |
50 | | -|**/Diag:[*file name*]**|Writes diagnostic trace logs to the specified file.| |
| 50 | +|**/Blame**|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 a sequence file in `TestResults/<Guid>/<Guid>_Sequence.xml` that captures the order of tests that were run before the crash.<br />You can also collect a crash or hang dump, for example `/Blame:CollectDump;DumpType=full` or `/Blame:CollectHangDump;TestTimeout=90m;HangDumpType=mini`. The equivalent `dotnet test` switches are `--blame-crash` and `--blame-hang`.<br />For the full option matrix and dump-collection requirements, see [Blame data collector](https://github.com/microsoft/vstest/blob/main/docs/extensions/blame-datacollector.md).| |
| 51 | +|**/Diag:[*file name*]**|Writes diagnostic trace logs to the specified file.<br />Set the trace level with `/Diag:<file name>;tracelevel=<off\|error\|warning\|info\|verbose>` (default is `verbose`).| |
51 | 52 | |**/ResultsDirectory:[*path*]**|Test results directory will be created in specified path if not exists.<br />Example: `/ResultsDirectory:<pathToResultsDirectory>`| |
52 | 53 | |**/ParentProcessId:[*parentProcessId*]**|Process ID of the Parent Process responsible for launching current process.| |
53 | 54 | |**/Port:[*port*]**|The Port for socket connection and receiving the event messages.| |
54 | 55 | |**/Collect:[*dataCollector friendlyName*]**|Enables data collector for the test run. [More information](https://github.com/microsoft/vstest/blob/main/docs/analyze.md).| |
| 56 | +|**@[*file*]**|Reads additional options from the specified response file. Arguments in the file are separated by whitespace (spaces or newlines) and quoting is supported, so options can span multiple lines.<br />Example: `vstest.console.exe @options.rsp`| |
55 | 57 |
|
56 | 58 | > [!TIP] |
57 | 59 | > The options and values aren't case-sensitive. |
@@ -101,6 +103,34 @@ Example of a generated *sequence.xml* file: |
101 | 103 | <Test Name="TestProject.UnitTest1.TestMethodA" Source="D:\repos\TestProject\TestProject\bin\Debug\TestProject.dll" /> |
102 | 104 | </TestSequence> |
103 | 105 | ``` |
| 106 | +In this case, the `<Test Name>` listed last is the test that was running at the time of the crash. |
| 107 | + |
| 108 | +## Exit codes |
| 109 | + |
| 110 | +*vstest.console.exe* returns one of two exit codes: |
| 111 | + |
| 112 | +| Code | Meaning | |
| 113 | +|---|---| |
| 114 | +| `0` | Success. The requested operation completed and, for a test run, all executed tests passed. | |
| 115 | +| `1` | Failure. For example, one or more tests failed, a run error was reported, the command line was invalid or missing, a test source couldn't be loaded, or the run was aborted or canceled. | |
| 116 | + |
| 117 | +The process never returns any other value. When you run tests through `dotnet test`, the .NET SDK surfaces a non-zero exit code when the run fails in the same way. |
| 118 | + |
| 119 | +When discovery finds no matching tests, the runner prints a *warning* rather than an error, and by default still returns `0`. To make a run that discovers or selects zero tests return `1` instead, set `<TreatNoTestsAsError>true</TreatNoTestsAsError>` in the **RunConfiguration** element of your *.runsettings* file. For more information, see [Configure unit tests using a .runsettings file](configure-unit-tests-by-using-a-dot-runsettings-file.md). |
| 120 | + |
| 121 | +## Escape filter expressions in the shell |
| 122 | + |
| 123 | +A **/TestCaseFilter** expression is parsed by both your shell and the test platform, so some characters need shell-specific escaping before *vstest.console.exe* receives them. Quoting the whole expression, as in the examples earlier in this article, avoids most problems. The following cases need extra care: |
| 124 | + |
| 125 | +- **PowerShell**: The comma (`,`) is the array operator and the semicolon (`;`) is a statement separator. Quote the entire filter expression so it's passed through literally, for example `/TestCaseFilter:"FullyQualifiedName=MyNamespace.MyClass.MyMethod"`. |
| 126 | +- **Bash and zsh (Linux and macOS)**: Escape `!` with a backslash when you use the `!~` (*not contains*) operator, for example `--filter FullyQualifiedName\!~IntegrationTests` with `dotnet test`. Also quote values that contain characters with special meaning to the shell, such as `<`, `>`, or `,` in a generic type argument list: |
| 127 | + |
| 128 | + ```bash |
| 129 | + dotnet test --filter "FullyQualifiedName=MyNamespace.MyClass<Type1,Type2>.MyMethod" |
| 130 | + ``` |
| 131 | + |
| 132 | +For the full filtering reference and supported properties per test framework, see [TestCase filter](https://github.com/microsoft/vstest/blob/main/docs/filter.md). |
| 133 | + |
104 | 134 | ## Logging example |
105 | 135 |
|
106 | 136 | Each logger defines its own parameters. Unlike trx, the console logger allows you to set verbosity level. For additional information, type `VSTest.Console/?` at the command line. |
|
0 commit comments