[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DYVJJ1XSFBFS8NGEC87NWX":3,"skill-same:01M6DYVJJ1XSFBFS8NGEC87NWX":92},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":63,"ownerHtmlUrl":64,"ownerBlogUrl":65,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M6DYVJJ1XSFBFS8NGEC87NWX","migrate-vstest-to-mtp",null,"Use this skill before answering, planning, or editing whenever .NET tests or CI are switching from VSTest to Microsoft.Testing.Platform (MTP), or an MTP migration behaves differently. Triggers include \"switch from VSTest\"; MSTest\u002FNUnit\u002FxUnit MTP enablement; OutputType=Exe only for test projects in Directory.Build.props; EnableMSTestRunner, EnableNUnitRunner, UseMicrosoftTestingPlatformRunner, or YTest.MTP.XUnit2; .NET 10 global.json test.runner and TestingPlatformDotnetTestSupport; translating VSTest filters, logger, coverage, blame, or dump arguments; replacing VSTest@3; and exit code 8 or zero tests. Also use for xUnit v3 MTP filters during a v2-to-v3 upgrade. Do not use for framework conversion, TFM, UWP, or WinUI.","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",514,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTesting\u002FOfficial-DotNet-Test-Migration\u002Fskills\u002Fmigrate-vstest-to-mtp\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"mtp","migrate vstest to mtp","migrate","conversion","for","dump","v3","triggers","tests","switching","platform","upgrade","runner","do","switch","exit","testing","filters","only","use","coverage","projects","ci","framework","winui","uwp","code","directory","2026-11-10 10:12:30",false,"---\nname: migrate-vstest-to-mtp\ndescription: >\n  Use this skill before answering, planning, or editing whenever .NET tests or\n  CI are switching from VSTest to Microsoft.Testing.Platform (MTP), or an MTP\n  migration behaves differently. Triggers include \"switch from VSTest\";\n  MSTest\u002FNUnit\u002FxUnit MTP enablement; OutputType=Exe only for test projects in\n  Directory.Build.props; EnableMSTestRunner, EnableNUnitRunner,\n  UseMicrosoftTestingPlatformRunner, or YTest.MTP.XUnit2; .NET 10 global.json\n  test.runner and TestingPlatformDotnetTestSupport; translating VSTest\n  filters, logger, coverage, blame, or dump arguments; replacing VSTest@3;\n  and exit code 8 or zero tests. Also use for xUnit v3 MTP filters during a\n  v2-to-v3 upgrade. Do not use for framework conversion, TFM, UWP, or WinUI.\nlicense: MIT\n---\n\n# VSTest -> Microsoft.Testing.Platform Migration\n\nMigrate a .NET test solution from VSTest to Microsoft.Testing.Platform (MTP). The outcome is a solution where all test projects run on MTP, `dotnet test` works correctly, and CI\u002FCD pipelines are updated.\n\n## First Action\n\nInspect the supplied project, `Directory.Build.props`, `global.json`, and CI\nfiles before searching the web or answering from memory. Resolve the framework\nand SDK mode first: .NET 9 and earlier use the compatibility property plus the\n`--` separator; .NET 10 native MTP uses `global.json`, removes that property,\nand passes MTP arguments without the separator. For central properties, never\ncondition on `IsTestProject` in `Directory.Build.props`; use a property already\navailable there, such as `MSBuildProjectName`.\n\n> **Important**: Do not mix VSTest-based and MTP-based .NET test projects in the same solution or run configuration -- this is an unsupported scenario.\n\n## When to Use\n\n- Switching from VSTest to Microsoft.Testing.Platform for any supported test framework\n- Enabling `dotnet run` \u002F `dotnet watch` \u002F direct executable execution for test projects\n- Enabling Native AOT or trimmed test execution\n- Replacing `vstest.console.exe` with `dotnet test` on MTP\n- Updating CI\u002FCD pipelines from the VSTest task to the .NET Core CLI task\n- Updating `dotnet test` arguments from VSTest syntax to MTP syntax\n\n## When Not to Use\n\n- The project already runs on Microsoft.Testing.Platform and there is no remaining MTP behavioral difference to resolve (e.g., exit code 8 for zero tests discovered)\n- Migrating between test frameworks (e.g., MSTest to xUnit.net) -- different effort entirely\n- The project builds UWP or packaged WinUI test projects -- MTP does not support these yet\n- The solution mixes .NET and non-.NET test adapters (e.g., JavaScript or C++ adapters) -- VSTest is required\n- Upgrading MSTest versions -- use `migrate-mstest-v1v2-to-v3` or `migrate-mstest-v3-to-v4`\n\n## Inputs\n\n| Input | Required | Description |\n|-------|----------|-------------|\n| Project or solution path | No | The `.csproj`, `.sln`, or `.slnx` entry point containing test projects. **Discover it yourself** by globbing the working directory; ask only when nothing is found or the choice is genuinely ambiguous |\n| Test framework | No | MSTest, NUnit, xUnit.net v2, or xUnit.net v3. Auto-detected from package references |\n| .NET SDK version | No | Determines `dotnet test` integration mode. Prefer the repository's `global.json` or explicitly stated CI SDK; use host `dotnet --version` only when the repository does not pin or state one |\n| CI\u002FCD pipeline files | No | Paths to pipeline definitions that invoke `vstest.console` or `dotnet test` |\n\n## Execution and Answer Contract\n\n- Discover project, props, `global.json`, and pipeline files in the current working directory. Open literal search results; the skill directory is not the user's repository. Continue after skill activation and do not ask for a discoverable path.\n- For an implementation request, edit the files, then validate the effective MSBuild properties, the translated command, test counts, and requested artifacts. For a question, provide one exact command\u002Fconfiguration for the detected SDK and framework rather than a menu of near-equivalents.\n- Preserve all build arguments and avoid introducing `--no-build`, new settings files, or unrelated package upgrades. Never retain `--settings \u003Cfile>` unless that file exists.\n- For .NET 9 and earlier, show the `--` separator. For .NET 10 native MTP mode, explicitly say to remove it.\n- When suppressing exit code 8 is intentional, warn that broad suppression can hide an accidental empty run caused by a bad filter; scope it to the known zero-test project\u002Fconfiguration.\n- For an exit-code-8 question, show all three concrete forms: `--ignore-exit-code 8`, `TestingPlatformCommandLineArguments`, and `TESTINGPLATFORM_EXITCODE_IGNORE=8`.\n- For xUnit v3 filters, give the directly usable `--filter-class`\u002F`--filter-method`\u002F`--filter-trait` command and explain AND behavior. When the resolved xUnit version supports it, include `--filter-query` path syntax for complex expressions and link the xUnit query-filter documentation.\n- When translating reporters, coverage, or dumps, name each required package in the answer; a correct-looking option without its owning extension package is incomplete.\n- Final results must name the framework runner opt-in, repository-selected SDK integration mode, exact translated command, extension packages, and verification evidence.\n\n## Workflow\n\n### Step 1: Assess the solution\n\n1. Identify the test framework for each test project -- see the `platform-detection` skill for the package-to-framework mapping. Key indicators:\n   - **MSTest**: References `MSTest` or `MSTest.TestAdapter`, or uses `MSTest.Sdk` (with `\u003CIsTestApplication>` not set to `false`). Note: `MSTest.TestFramework` alone is a library dependency, not a test project.\n   - **NUnit**: References `NUnit3TestAdapter`\n   - **xUnit.net**: References `xunit` and `xunit.runner.visualstudio`\n2. Resolve the SDK used by the repository\u002FCI from `global.json` or explicit user context. Fall back to `dotnet --version` only when neither exists; the agent host SDK must not silently override a stated .NET 8\u002F9 CI target.\n3. Check whether a `Directory.Build.props` file exists at the solution or repo root -- all MTP properties should go there for consistency\n4. Check for `vstest.console.exe` usage in CI scripts or pipeline definitions\n5. Check for VSTest-specific `dotnet test` arguments in CI scripts: `--filter`, `--logger`, `--collect`, `--settings`, `--blame*`\n6. Run `dotnet test` to establish a baseline of test pass\u002Ffail counts\n\n### Step 2: Set up Directory.Build.props\n\n> **Critical**: Set MTP runner properties in `Directory.Build.props` at the solution or repo root whenever possible, rather than per-project. This prevents inconsistent configuration where some projects use VSTest and others use MTP (an unsupported scenario).\n> **Note**: MTP also requires test projects to have `\u003COutputType>Exe\u003C\u002FOutputType>`. Only `MSTest.Sdk` sets this automatically. For all other setups (MSTest NuGet packages with `EnableMSTestRunner`, NUnit with `EnableNUnitRunner`, xUnit.net with `YTest.MTP.XUnit2`), prefer setting `\u003COutputType>Exe\u003C\u002FOutputType>` centrally in `Directory.Build.props` with a condition that targets only test projects. If you cannot reliably target only test projects from `Directory.Build.props`, setting `\u003COutputType>Exe\u003C\u002FOutputType>` per-project is an acceptable exception.\n>\n> **Conditioning in `Directory.Build.props`**: Do NOT use `Condition=\"'$(IsTestProject)' == 'true'\"` -- `IsTestProject` is set by the test SDK targets later in evaluation and is not available when `Directory.Build.props` is imported. Use a property that is available early, such as `MSBuildProjectName`, to target test projects by naming convention. For example, if all test projects end in `.Tests`:\n>\n> ```xml\n> \u003CPropertyGroup Condition=\"$(MSBuildProjectName.EndsWith('.Tests'))\">\n>   \u003COutputType>Exe\u003C\u002FOutputType>\n> \u003C\u002FPropertyGroup>\n> ```\n>\n> Adjust the condition (e.g., `.EndsWith('Tests')`, `.Contains('.Test')`) to match the test project naming convention used in the repository.\n>\n> Put every applicable central property in that same condition: `OutputType`,\n> the framework runner opt-in, and `TestingPlatformDotnetTestSupport` on .NET 9\n> and earlier. Do not leave an unconditional runner property that still affects\n> production projects.\n\n### Step 3: Enable the framework-specific MTP runner\n\nEach framework has its own opt-in property. Add these in `Directory.Build.props` for consistency.\n\n#### MSTest\n\n**Option A -- MSTest NuGet packages (3.2.0+):**\n\n```xml\n\u003CPropertyGroup>\n  \u003CEnableMSTestRunner>true\u003C\u002FEnableMSTestRunner>\n  \u003COutputType>Exe\u003C\u002FOutputType>\n\u003C\u002FPropertyGroup>\n```\n\nEnsure the project references MSTest 3.2.0 or later. If the version is already 3.2.0+, no MSTest version upgrade is needed for MTP migration.\n\n**Option B -- MSTest.Sdk:**\n\nWhen using `MSTest.Sdk`, MTP is enabled by default -- no `EnableMSTestRunner` or `OutputType Exe` property is needed (the SDK sets both automatically). The only action is: if the project has `\u003CUseVSTest>true\u003C\u002FUseVSTest>`, **remove it**. That property forces the project to use VSTest instead of MTP.\n\n#### NUnit\n\nRequires `NUnit3TestAdapter` **5.0.0** or later.\n\n1. Update `NUnit3TestAdapter` to 5.0.0+:\n\n```xml\n\u003CPackageReference Include=\"NUnit3TestAdapter\" Version=\"5.0.0\" \u002F>\n```\n\n1. Enable the NUnit runner:\n\n```xml\n\u003CPropertyGroup>\n  \u003CEnableNUnitRunner>true\u003C\u002FEnableNUnitRunner>\n  \u003COutputType>Exe\u003C\u002FOutputType>\n\u003C\u002FPropertyGroup>\n```\n\n#### xUnit.net\n\nAdd a reference to `YTest.MTP.XUnit2` -- this package provides MTP support for xUnit.net v2 projects without requiring an upgrade to xunit.v3. You must also set `OutputType` to `Exe`:\n\n```xml\n\u003CPackageReference Include=\"YTest.MTP.XUnit2\" Version=\"0.4.0\" \u002F>\n```\n\n```xml\n\u003CPropertyGroup>\n  \u003COutputType>Exe\u003C\u002FOutputType>\n\u003C\u002FPropertyGroup>\n```\n\n> **Note**: `YTest.MTP.XUnit2` preserves the VSTest `--filter` syntax, so no filter migration is needed for xUnit.net v2. It also supports `--settings` for runsettings (xunit-specific configurations only), `xunit.runner.json`, TRX reporting via `--report-trx`, and `--treenode-filter`.\n\n#### xUnit.net v3\n\nxUnit.net v3 (`xunit.v3` package) has built-in MTP support. Enable it with:\n\n```xml\n\u003CPropertyGroup>\n  \u003CUseMicrosoftTestingPlatformRunner>true\u003C\u002FUseMicrosoftTestingPlatformRunner>\n\u003C\u002FPropertyGroup>\n```\n\n> **Important**: xUnit.net v3 on MTP does NOT support the VSTest `--filter` syntax. You must translate filters to xUnit.net v3's native filter options (see Step 5).\n\n### Step 4: Configure dotnet test integration\n\nThe `dotnet test` integration depends on the .NET SDK version.\n\n#### .NET 10 SDK and later (recommended)\n\nUse the native MTP mode by adding a `test` section to `global.json`:\n\n```json\n{\n  \"sdk\": {\n    \"version\": \"10.0.100\"\n  },\n  \"test\": {\n    \"runner\": \"Microsoft.Testing.Platform\"\n  }\n}\n```\n\nIn this mode, `dotnet test` arguments are passed directly -- for example, `dotnet test --report-trx`.\n\n> **Important**: `global.json` does not support trailing commas. Ensure the JSON is strictly valid.\n\n#### .NET 9 SDK and earlier\n\nUse the VSTest mode of `dotnet test` command to run MTP test projects by adding this property in `Directory.Build.props`:\n\n```xml\n\u003CPropertyGroup>\n  \u003CTestingPlatformDotnetTestSupport>true\u003C\u002FTestingPlatformDotnetTestSupport>\n\u003C\u002FPropertyGroup>\n```\n\n> **Important**: In this mode, you must use `--` to separate `dotnet test` build arguments from MTP arguments. For example: `dotnet test --no-build -- --list-tests`.\n\n### Step 5: Update dotnet test command-line arguments\n\nVSTest-specific arguments must be translated to MTP equivalents. Build-related arguments (`-c`, `-f`, `--no-build`, `--nologo`, `-v`, etc.) are unchanged.\n\n| VSTest argument | MTP equivalent | Notes |\n|-----------------|----------------|-------|\n| `--test-adapter-path` | Not applicable | MTP does not use external adapter discovery |\n| `--blame` | Not applicable | |\n| `--blame-crash` | `--crashdump` | Requires `Microsoft.Testing.Extensions.CrashDump` NuGet package |\n| `--blame-crash-dump-type \u003CTYPE>` | `--crashdump-type \u003CTYPE>` | Requires CrashDump extension |\n| `--blame-hang` | `--hangdump` | Requires `Microsoft.Testing.Extensions.HangDump` NuGet package |\n| `--blame-hang-dump-type \u003CTYPE>` | `--hangdump-type \u003CTYPE>` | Requires HangDump extension |\n| `--blame-hang-timeout \u003CTIMESPAN>` | `--hangdump-timeout \u003CTIMESPAN>` | Requires HangDump extension |\n| `--collect \"Code Coverage;Format=cobertura\"` | `--coverage --coverage-output-format cobertura` | Per-extension arguments |\n| `-d\\|--diag \u003CLOG_FILE>` | `--diagnostic` | |\n| `--filter \u003CEXPRESSION>` | `--filter \u003CEXPRESSION>` | Same syntax for MSTest, NUnit, and xUnit.net v2 (with `YTest.MTP.XUnit2`). For xUnit.net v3, see filter migration below |\n| `-l\\|--logger trx` | `--report-trx` | Requires `Microsoft.Testing.Extensions.TrxReport` NuGet package |\n| `--results-directory \u003CDIR>` | `--results-directory \u003CDIR>` | Same |\n| `-s\\|--settings \u003CFILE>` | `--settings \u003CFILE>` | MSTest and NUnit still support `.runsettings` |\n| `-t\\|--list-tests` | `--list-tests` | Same |\n| `-- \u003CRunSettings args>` | `--test-parameter` | Applicable only to MSTest and NUnit |\n\n#### Filter migration\n\n**MSTest, NUnit, and xUnit.net v2 (with `YTest.MTP.XUnit2`)**: The VSTest `--filter` syntax is identical on both VSTest and MTP. No changes needed.\n\n**xUnit.net v3 (native MTP)**: xUnit.net v3 does NOT support the VSTest `--filter` syntax on MTP. You must translate filters to xUnit.net v3's native filter options.\n\n#### xUnit.net v3 filter flags\n\n| Flag | Description |\n|------|-------------|\n| `--filter-class \"name\"` | Run all tests in a given class. Supports wildcards (`*`). |\n| `--filter-not-class \"name\"` | Exclude all tests in a given class |\n| `--filter-method \"name\"` | Run a specific test method |\n| `--filter-not-method \"name\"` | Exclude a specific test method |\n| `--filter-namespace \"name\"` | Run all tests in a namespace |\n| `--filter-not-namespace \"name\"` | Exclude all tests in a namespace |\n| `--filter-trait \"name=value\"` | Run tests with a matching trait |\n| `--filter-not-trait \"name=value\"` | Exclude tests with a matching trait |\n\nMultiple values can be specified with a single flag: `--filter-class Foo Bar`.\n\n#### VSTest → xUnit.net v3 filter translation table\n\n| VSTest `--filter` syntax | xUnit.net v3 MTP equivalent | Notes |\n|---|---|---|\n| `FullyQualifiedName~ClassName` | `--filter-class *ClassName*` | Wildcards required for substring match |\n| `FullyQualifiedName=Ns.Class.Method` | `--filter-method Ns.Class.Method` | Exact match on fully qualified method |\n| `Name=MethodName` | `--filter-method *MethodName*` | Wildcards for substring match |\n| `Category=Value` (trait) | `--filter-trait \"Category=Value\"` | Filter by trait name\u002Fvalue pair |\n| Complex expressions | `--filter-query \"expr\"` | Uses xUnit.net query filter language (see below) |\n\n#### xUnit.net v3 query filter language\n\nFor complex expressions, use `--filter-query` with a path-segment syntax:\n\n```text\n\u002F\u003CassemblyFilter>\u002F\u003CnamespaceFilter>\u002F\u003CclassFilter>\u002F\u003CmethodFilter>[traitName=traitValue]\n```\n\nEach segment matches against: assembly name, namespace, class name, method name. Use `*` for \"match all\" in any segment. Documentation: \u003Chttps:\u002F\u002Fxunit.net\u002Fdocs\u002Fquery-filter-language>\n\nPrefer the directly corresponding `--filter-class` \u002F `--filter-method` \u002F\n`--filter-trait` flags when they express the original filter. Use\n`--filter-query` only after validating the query with `--list-tests`; a\nsyntactically accepted query that selects zero tests is not a successful\ntranslation.\n\n#### Translation example\n\n```shell\n# VSTest\ndotnet test --filter \"FullyQualifiedName~IntegrationTests&Category=Smoke\"\n\n# xUnit.net v3 MTP -- using individual filters (AND behavior)\ndotnet test -- --filter-class *IntegrationTests* --filter-trait \"Category=Smoke\"\n\n# xUnit.net v3 MTP -- using query language (assembly\u002Fnamespace\u002Fclass\u002Fmethod[trait])\ndotnet test -- --filter-query \"\u002F*\u002F*\u002F*IntegrationTests*\u002F*[Category=Smoke]\"\n```\n\n> **Note**: When combining `--filter-class` and `--filter-trait`, both conditions must match (AND behavior). For complex expressions, use `--filter-query` with the path-segment syntax. See the [xUnit.net query filter language docs](https:\u002F\u002Fxunit.net\u002Fdocs\u002Fquery-filter-language) for full reference.\n\n### Step 6: Install MTP extension packages (if needed)\n\nIf CI scripts use TRX reporting, crash dumps, hang dumps, or coverage, add the\nowning packages. Under Central Package Management, the project references are:\n\n```xml\n\u003CItemGroup>\n  \u003CPackageReference Include=\"Microsoft.Testing.Extensions.TrxReport\" \u002F>\n  \u003CPackageReference Include=\"Microsoft.Testing.Extensions.CrashDump\" \u002F>\n  \u003CPackageReference Include=\"Microsoft.Testing.Extensions.HangDump\" \u002F>\n  \u003CPackageReference Include=\"Microsoft.Testing.Extensions.CodeCoverage\" \u002F>\n\u003C\u002FItemGroup>\n```\n\nAdd matching `PackageVersion` entries in `Directory.Packages.props`. Without\nCentral Package Management, put exact versions resolved from the configured\nfeed on these references. Keep the versions compatible with the selected MTP\nstack; do not copy fixed versions from migration guidance.\n\n### Step 7: Update CI\u002FCD pipelines\n\n#### Azure DevOps\n\n**If using the VSTest task (`VSTest@3`)**: Replace with the .NET Core CLI task (`DotNetCoreCLI@2`):\n\n```yaml\n# Before (VSTest task)\n- task: VSTest@3\n  inputs:\n    testAssemblyVer2: '**\u002F*Tests.dll'\n    runSettingsFile: 'test.runsettings'\n\n# After (.NET Core CLI task)\n- task: DotNetCoreCLI@2\n  displayName: Run tests\n  inputs:\n    command: 'test'\n    arguments: '--no-build --configuration Release'\n```\n\n**If already using DotNetCoreCLI@2**: Update arguments per Step 5 translations. Remember the `--` separator on .NET 9 and earlier:\n\n```yaml\n- task: DotNetCoreCLI@2\n  displayName: Run tests\n  inputs:\n    command: 'test'\n    arguments: '--no-build -- --report-trx --results-directory $(Agent.TempDirectory)'\n```\n\n#### GitHub Actions\n\nUpdate `dotnet test` invocations in workflow files with the same argument translations from Step 5.\n\n#### Replace vstest.console.exe\n\nIf any script invokes `vstest.console.exe` directly, replace it with `dotnet test`. The test projects are now executables and can also be run directly.\n\n### Step 8: Handle behavioral differences\n\n#### Zero tests exit code\n\nVSTest silently succeeds when zero tests are discovered. MTP fails with **exit code 8**. Options:\n\n- Pass `--ignore-exit-code 8` when running tests\n- Add to `Directory.Build.props`:\n\n```xml\n\u003CPropertyGroup>\n  \u003CTestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8\u003C\u002FTestingPlatformCommandLineArguments>\n\u003C\u002FPropertyGroup>\n```\n\n- Use environment variable: `TESTINGPLATFORM_EXITCODE_IGNORE=8`\n\n### Step 9: Remove VSTest-only packages (optional)\n\nOnce migration is complete and verified, remove packages that are only needed for VSTest:\n\n- `Microsoft.NET.Test.Sdk` -- not needed for MTP (MSTest.Sdk v4 already omits it by default)\n- `xunit.runner.visualstudio` -- only needed for VSTest discovery of xUnit.net (not needed when using `YTest.MTP.XUnit2`)\n- `NUnit3TestAdapter` VSTest-only features -- the adapter is still needed but only for the MTP runner\n\n> **Note**: If you need to maintain VSTest compatibility during a transition period, keep these packages.\n\n### Step 10: Verify\n\n1. Run `dotnet build` -- confirm zero errors\n2. Run `dotnet test` -- confirm all tests pass\n3. Compare test pass\u002Ffail counts to the pre-migration baseline\n4. Run the test executable directly (e.g., `.\u002Fbin\u002FDebug\u002Fnet8.0\u002FMyTests.exe`) -- confirm it works\n5. Verify CI pipeline produces the expected test result artifacts (TRX files, code coverage, crash dumps)\n6. Test that Test Explorer in Visual Studio (17.14+) or VS Code discovers and runs tests\n\n## Validation\n\n- [ ] All test projects use MTP runner (no VSTest-only configuration remains)\n- [ ] `dotnet build` completes with zero errors\n- [ ] `dotnet test` passes all tests and test counts match pre-migration baseline\n- [ ] Test executable runs directly (e.g., `.\u002Fbin\u002FDebug\u002Fnet8.0\u002FMyTests.exe`)\n- [ ] CI pipeline produces expected test result artifacts (TRX files, code coverage, crash dumps)\n- [ ] Test Explorer in Visual Studio or VS Code discovers and runs tests\n- [ ] No `vstest.console.exe` invocations remain in CI scripts\n- [ ] `\u003COutputType>Exe\u003C\u002FOutputType>` is set for all non-MSTest.Sdk test projects\n\n## Common Pitfalls\n\n| Pitfall | Solution |\n|---------|----------|\n| Mixing VSTest and MTP projects in the same solution | Migrate all test projects together -- mixed mode is unsupported |\n| `dotnet test` arguments ignored on .NET 9 and earlier | Use `--` to separate build args from MTP args: `dotnet test -- --report-trx` |\n| Exit code 8 on CI without failures | MTP fails when zero tests run; use `--ignore-exit-code 8` or fix test discovery |\n| MSTest.Sdk v4 + vstest.console no longer works | MSTest.Sdk v4 no longer adds `Microsoft.NET.Test.Sdk` -- add it explicitly or switch to `dotnet test` |\n| Missing `\u003COutputType>Exe\u003C\u002FOutputType>` | Required for all setups except MSTest.Sdk (which sets it automatically) |\n| Using `Condition=\"'$(IsTestProject)' == 'true'\"` in `Directory.Build.props` | `IsTestProject` is not yet defined when `Directory.Build.props` is evaluated -- use `$(MSBuildProjectName.EndsWith('.Tests'))` (or a similar name-based check) instead |\n\n## Next Steps\n\n- Use `run-tests` for running tests on the new MTP platform\n- Use `mtp-hot-reload` for iterative test fixing with hot reload on MTP\n\n## More Info\n\n- [Test platforms overview](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Ftest-platforms-overview)\n- [Migrate from VSTest to Microsoft.Testing.Platform](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Fmigrating-vstest-microsoft-testing-platform)\n- [Microsoft.Testing.Platform overview](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Fmicrosoft-testing-platform-intro)\n- [Testing with dotnet test](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Funit-testing-with-dotnet-test)\n- [Microsoft.Testing.Platform CLI options](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Fmicrosoft-testing-platform-cli-options)\n- [Microsoft.Testing.Platform extensions](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Funit-testing-platform-extensions)\n","# VSTest -> Microsoft.Testing.Platform Migration\n\nMigrate a .NET test solution from VSTest to Microsoft.Testing.Platform (MTP). The outcome is a solution where all test projects run on MTP, `dotnet test` works correctly, and CI\u002FCD pipelines are updated.\n\n## First Action\n\nInspect the supplied project, `Directory.Build.props`, `global.json`, and CI\nfiles before searching the web or answering from memory. Resolve the framework\nand SDK mode first: .NET 9 and earlier use the compatibility property plus the\n`--` separator; .NET 10 native MTP uses `global.json`, removes that property,\nand passes MTP arguments without the separator. For central properties, never\ncondition on `IsTestProject` in `Directory.Build.props`; use a property already\navailable there, such as `MSBuildProjectName`.\n\n> **Important**: Do not mix VSTest-based and MTP-based .NET test projects in the same solution or run configuration -- this is an unsupported scenario.\n\n## When to Use\n\n- Switching from VSTest to Microsoft.Testing.Platform for any supported test framework\n- Enabling `dotnet run` \u002F `dotnet watch` \u002F direct executable execution for test projects\n- Enabling Native AOT or trimmed test execution\n- Replacing `vstest.console.exe` with `dotnet test` on MTP\n- Updating CI\u002FCD pipelines from the VSTest task to the .NET Core CLI task\n- Updating `dotnet test` arguments from VSTest syntax to MTP syntax\n\n## When Not to Use\n\n- The project already runs on Microsoft.Testing.Platform and there is no remaining MTP behavioral difference to resolve (e.g., exit code 8 for zero tests discovered)\n- Migrating between test frameworks (e.g., MSTest to xUnit.net) -- different effort entirely\n- The project builds UWP or packaged WinUI test projects -- MTP does not support these yet\n- The solution mixes .NET and non-.NET test adapters (e.g., JavaScript or C++ adapters) -- VSTest is required\n- Upgrading MSTest versions -- use `migrate-mstest-v1v2-to-v3` or `migrate-mstest-v3-to-v4`\n\n## Inputs\n\n| Input | Required | Description |\n|-------|----------|-------------|\n| Project or solution path | No | The `.csproj`, `.sln`, or `.slnx` entry point containing test projects. **Discover it yourself** by globbing the working directory; ask only when nothing is found or the choice is genuinely ambiguous |\n| Test framework | No | MSTest, NUnit, xUnit.net v2, or xUnit.net v3. Auto-detected from package references |\n| .NET SDK version | No | Determines `dotnet test` integration mode. Prefer the repository's `global.json` or explicitly stated CI SDK; use host `dotnet --version` only when the repository does not pin or state one |\n| CI\u002FCD pipeline files | No | Paths to pipeline definitions that invoke `vstest.console` or `dotnet test` |\n\n## Execution and Answer Contract\n\n- Discover project, props, `global.json`, and pipeline files in the current working directory. Open literal search results; the skill directory is not the user's repository. Continue after skill activation and do not ask for a discoverable path.\n- For an implementation request, edit the files, then validate the effective MSBuild properties, the translated command, test counts, and requested artifacts. For a question, provide one exact command\u002Fconfiguration for the detected SDK and framework rather than a menu of near-equivalents.\n- Preserve all build arguments and avoid introducing `--no-build`, new settings files, or unrelated package upgrades. Never retain `--settings \u003Cfile>` unless that file exists.\n- For .NET 9 and earlier, show the `--` separator. For .NET 10 native MTP mode, explicitly say to remove it.\n- When suppressing exit code 8 is intentional, warn that broad suppression can hide an accidental empty run caused by a bad filter; scope it to the known zero-test project\u002Fconfiguration.\n- For an exit-code-8 question, show all three concrete forms: `--ignore-exit-code 8`, `TestingPlatformCommandLineArguments`, and `TESTINGPLATFORM_EXITCODE_IGNORE=8`.\n- For xUnit v3 filters, give the directly usable `--filter-class`\u002F`--filter-method`\u002F`--filter-trait` command and explain AND behavior. When the resolved xUnit version supports it, include `--filter-query` path syntax for complex expressions and link the xUnit query-filter documentation.\n- When translating reporters, coverage, or dumps, name each required package in the answer; a correct-looking option without its owning extension package is incomplete.\n- Final results must name the framework runner opt-in, repository-selected SDK integration mode, exact translated command, extension packages, and verification evidence.\n\n## Workflow\n\n### Step 1: Assess the solution\n\n1. Identify the test framework for each test project -- see the `platform-detection` skill for the package-to-framework mapping. Key indicators:\n   - **MSTest**: References `MSTest` or `MSTest.TestAdapter`, or uses `MSTest.Sdk` (with `\u003CIsTestApplication>` not set to `false`). Note: `MSTest.TestFramework` alone is a library dependency, not a test project.\n   - **NUnit**: References `NUnit3TestAdapter`\n   - **xUnit.net**: References `xunit` and `xunit.runner.visualstudio`\n2. Resolve the SDK used by the repository\u002FCI from `global.json` or explicit user context. Fall back to `dotnet --version` only when neither exists; the agent host SDK must not silently override a stated .NET 8\u002F9 CI target.\n3. Check whether a `Directory.Build.props` file exists at the solution or repo root -- all MTP properties should go there for consistency\n4. Check for `vstest.console.exe` usage in CI scripts or pipeline definitions\n5. Check for VSTest-specific `dotnet test` arguments in CI scripts: `--filter`, `--logger`, `--collect`, `--settings`, `--blame*`\n6. Run `dotnet test` to establish a baseline of test pass\u002Ffail counts\n\n### Step 2: Set up Directory.Build.props\n\n> **Critical**: Set MTP runner properties in `Directory.Build.props` at the solution or repo root whenever possible, rather than per-project. This prevents inconsistent configuration where some projects use VSTest and others use MTP (an unsupported scenario).\n> **Note**: MTP also requires test projects to have `\u003COutputType>Exe\u003C\u002FOutputType>`. Only `MSTest.Sdk` sets this automatically. For all other setups (MSTest NuGet packages with `EnableMSTestRunner`, NUnit with `EnableNUnitRunner`, xUnit.net with `YTest.MTP.XUnit2`), prefer setting `\u003COutputType>Exe\u003C\u002FOutputType>` centrally in `Directory.Build.props` with a condition that targets only test projects. If you cannot reliably target only test projects from `Directory.Build.props`, setting `\u003COutputType>Exe\u003C\u002FOutputType>` per-project is an acceptable exception.\n>\n> **Conditioning in `Directory.Build.props`**: Do NOT use `Condition=\"'$(IsTestProject)' == 'true'\"` -- `IsTestProject` is set by the test SDK targets later in evaluation and is not available when `Directory.Build.props` is imported. Use a property that is available early, such as `MSBuildProjectName`, to target test projects by naming convention. For example, if all test projects end in `.Tests`:\n>\n> ```xml\n> \u003CPropertyGroup Condition=\"$(MSBuildProjectName.EndsWith('.Tests'))\">\n>   \u003COutputType>Exe\u003C\u002FOutputType>\n> \u003C\u002FPropertyGroup>\n> ```\n>\n> Adjust the condition (e.g., `.EndsWith('Tests')`, `.Contains('.Test')`) to match the test project naming convention used in the repository.\n>\n> Put every applicable central property in that same condition: `OutputType`,\n> the framework runner opt-in, and `TestingPlatformDotnetTestSupport` on .NET 9\n> and earlier. Do not leave an unconditional runner property that still affects\n> production projects.\n\n### Step 3: Enable the framework-specific MTP runner\n\nEach framework has its own opt-in property. Add these in `Directory.Build.props` for consistency.\n\n#### MSTest\n\n**Option A -- MSTest NuGet packages (3.2.0+):**\n\n```xml\n\u003CPropertyGroup>\n  \u003CEnableMSTestRunner>true\u003C\u002FEnableMSTestRunner>\n  \u003COutputType>Exe\u003C\u002FOutputType>\n\u003C\u002FPropertyGroup>\n```\n\nEnsure the project references MSTest 3.2.0 or later. If the version is already 3.2.0+, no MSTest version upgrade is needed for MTP migration.\n\n**Option B -- MSTest.Sdk:**\n\nWhen using `MSTest.Sdk`, MTP is enabled by default -- no `EnableMSTestRunner` or `OutputType Exe` property is needed (the SDK sets both automatically). The only action is: if the project has `\u003CUseVSTest>true\u003C\u002FUseVSTest>`, **remove it**. That property forces the project to use VSTest instead of MTP.\n\n#### NUnit\n\nRequires `NUnit3TestAdapter` **5.0.0** or later.\n\n1. Update `NUnit3TestAdapter` to 5.0.0+:\n\n```xml\n\u003CPackageReference Include=\"NUnit3TestAdapter\" Version=\"5.0.0\" \u002F>\n```\n\n1. Enable the NUnit runner:\n\n```xml\n\u003CPropertyGroup>\n  \u003CEnableNUnitRunner>true\u003C\u002FEnableNUnitRunner>\n  \u003COutputType>Exe\u003C\u002FOutputType>\n\u003C\u002FPropertyGroup>\n```\n\n#### xUnit.net\n\nAdd a reference to `YTest.MTP.XUnit2` -- this package provides MTP support for xUnit.net v2 projects without requiring an upgrade to xunit.v3. You must also set `OutputType` to `Exe`:\n\n```xml\n\u003CPackageReference Include=\"YTest.MTP.XUnit2\" Version=\"0.4.0\" \u002F>\n```\n\n```xml\n\u003CPropertyGroup>\n  \u003COutputType>Exe\u003C\u002FOutputType>\n\u003C\u002FPropertyGroup>\n```\n\n> **Note**: `YTest.MTP.XUnit2` preserves the VSTest `--filter` syntax, so no filter migration is needed for xUnit.net v2. It also supports `--settings` for runsettings (xunit-specific configurations only), `xunit.runner.json`, TRX reporting via `--report-trx`, and `--treenode-filter`.\n\n#### xUnit.net v3\n\nxUnit.net v3 (`xunit.v3` package) has built-in MTP support. Enable it with:\n\n```xml\n\u003CPropertyGroup>\n  \u003CUseMicrosoftTestingPlatformRunner>true\u003C\u002FUseMicrosoftTestingPlatformRunner>\n\u003C\u002FPropertyGroup>\n```\n\n> **Important**: xUnit.net v3 on MTP does NOT support the VSTest `--filter` syntax. You must translate filters to xUnit.net v3's native filter options (see Step 5).\n\n### Step 4: Configure dotnet test integration\n\nThe `dotnet test` integration depends on the .NET SDK version.\n\n#### .NET 10 SDK and later (recommended)\n\nUse the native MTP mode by adding a `test` section to `global.json`:\n\n```json\n{\n  \"sdk\": {\n    \"version\": \"10.0.100\"\n  },\n  \"test\": {\n    \"runner\": \"Microsoft.Testing.Platform\"\n  }\n}\n```\n\nIn this mode, `dotnet test` arguments are passed directly -- for example, `dotnet test --report-trx`.\n\n> **Important**: `global.json` does not support trailing commas. Ensure the JSON is strictly valid.\n\n#### .NET 9 SDK and earlier\n\nUse the VSTest mode of `dotnet test` command to run MTP test projects by adding this property in `Directory.Build.props`:\n\n```xml\n\u003CPropertyGroup>\n  \u003CTestingPlatformDotnetTestSupport>true\u003C\u002FTestingPlatformDotnetTestSupport>\n\u003C\u002FPropertyGroup>\n```\n\n> **Important**: In this mode, you must use `--` to separate `dotnet test` build arguments from MTP arguments. For example: `dotnet test --no-build -- --list-tests`.\n\n### Step 5: Update dotnet test command-line arguments\n\nVSTest-specific arguments must be translated to MTP equivalents. Build-related arguments (`-c`, `-f`, `--no-build`, `--nologo`, `-v`, etc.) are unchanged.\n\n| VSTest argument | MTP equivalent | Notes |\n|-----------------|----------------|-------|\n| `--test-adapter-path` | Not applicable | MTP does not use external adapter discovery |\n| `--blame` | Not applicable | |\n| `--blame-crash` | `--crashdump` | Requires `Microsoft.Testing.Extensions.CrashDump` NuGet package |\n| `--blame-crash-dump-type \u003CTYPE>` | `--crashdump-type \u003CTYPE>` | Requires CrashDump extension |\n| `--blame-hang` | `--hangdump` | Requires `Microsoft.Testing.Extensions.HangDump` NuGet package |\n| `--blame-hang-dump-type \u003CTYPE>` | `--hangdump-type \u003CTYPE>` | Requires HangDump extension |\n| `--blame-hang-timeout \u003CTIMESPAN>` | `--hangdump-timeout \u003CTIMESPAN>` | Requires HangDump extension |\n| `--collect \"Code Coverage;Format=cobertura\"` | `--coverage --coverage-output-format cobertura` | Per-extension arguments |\n| `-d\\|--diag \u003CLOG_FILE>` | `--diagnostic` | |\n| `--filter \u003CEXPRESSION>` | `--filter \u003CEXPRESSION>` | Same syntax for MSTest, NUnit, and xUnit.net v2 (with `YTest.MTP.XUnit2`). For xUnit.net v3, see filter migration below |\n| `-l\\|--logger trx` | `--report-trx` | Requires `Microsoft.Testing.Extensions.TrxReport` NuGet package |\n| `--results-directory \u003CDIR>` | `--results-directory \u003CDIR>` | Same |\n| `-s\\|--settings \u003CFILE>` | `--settings \u003CFILE>` | MSTest and NUnit still support `.runsettings` |\n| `-t\\|--list-tests` | `--list-tests` | Same |\n| `-- \u003CRunSettings args>` | `--test-parameter` | Applicable only to MSTest and NUnit |\n\n#### Filter migration\n\n**MSTest, NUnit, and xUnit.net v2 (with `YTest.MTP.XUnit2`)**: The VSTest `--filter` syntax is identical on both VSTest and MTP. No changes needed.\n\n**xUnit.net v3 (native MTP)**: xUnit.net v3 does NOT support the VSTest `--filter` syntax on MTP. You must translate filters to xUnit.net v3's native filter options.\n\n#### xUnit.net v3 filter flags\n\n| Flag | Description |\n|------|-------------|\n| `--filter-class \"name\"` | Run all tests in a given class. Supports wildcards (`*`). |\n| `--filter-not-class \"name\"` | Exclude all tests in a given class |\n| `--filter-method \"name\"` | Run a specific test method |\n| `--filter-not-method \"name\"` | Exclude a specific test method |\n| `--filter-namespace \"name\"` | Run all tests in a namespace |\n| `--filter-not-namespace \"name\"` | Exclude all tests in a namespace |\n| `--filter-trait \"name=value\"` | Run tests with a matching trait |\n| `--filter-not-trait \"name=value\"` | Exclude tests with a matching trait |\n\nMultiple values can be specified with a single flag: `--filter-class Foo Bar`.\n\n#### VSTest → xUnit.net v3 filter translation table\n\n| VSTest `--filter` syntax | xUnit.net v3 MTP equivalent | Notes |\n|---|---|---|\n| `FullyQualifiedName~ClassName` | `--filter-class *ClassName*` | Wildcards required for substring match |\n| `FullyQualifiedName=Ns.Class.Method` | `--filter-method Ns.Class.Method` | Exact match on fully qualified method |\n| `Name=MethodName` | `--filter-method *MethodName*` | Wildcards for substring match |\n| `Category=Value` (trait) | `--filter-trait \"Category=Value\"` | Filter by trait name\u002Fvalue pair |\n| Complex expressions | `--filter-query \"expr\"` | Uses xUnit.net query filter language (see below) |\n\n#### xUnit.net v3 query filter language\n\nFor complex expressions, use `--filter-query` with a path-segment syntax:\n\n```text\n\u002F\u003CassemblyFilter>\u002F\u003CnamespaceFilter>\u002F\u003CclassFilter>\u002F\u003CmethodFilter>[traitName=traitValue]\n```\n\nEach segment matches against: assembly name, namespace, class name, method name. Use `*` for \"match all\" in any segment. Documentation: \u003Chttps:\u002F\u002Fxunit.net\u002Fdocs\u002Fquery-filter-language>\n\nPrefer the directly corresponding `--filter-class` \u002F `--filter-method` \u002F\n`--filter-trait` flags when they express the original filter. Use\n`--filter-query` only after validating the query with `--list-tests`; a\nsyntactically accepted query that selects zero tests is not a successful\ntranslation.\n\n#### Translation example\n\n```shell\n# VSTest\ndotnet test --filter \"FullyQualifiedName~IntegrationTests&Category=Smoke\"\n\n# xUnit.net v3 MTP -- using individual filters (AND behavior)\ndotnet test -- --filter-class *IntegrationTests* --filter-trait \"Category=Smoke\"\n\n# xUnit.net v3 MTP -- using query language (assembly\u002Fnamespace\u002Fclass\u002Fmethod[trait])\ndotnet test -- --filter-query \"\u002F*\u002F*\u002F*IntegrationTests*\u002F*[Category=Smoke]\"\n```\n\n> **Note**: When combining `--filter-class` and `--filter-trait`, both conditions must match (AND behavior). For complex expressions, use `--filter-query` with the path-segment syntax. See the [xUnit.net query filter language docs](https:\u002F\u002Fxunit.net\u002Fdocs\u002Fquery-filter-language) for full reference.\n\n### Step 6: Install MTP extension packages (if needed)\n\nIf CI scripts use TRX reporting, crash dumps, hang dumps, or coverage, add the\nowning packages. Under Central Package Management, the project references are:\n\n```xml\n\u003CItemGroup>\n  \u003CPackageReference Include=\"Microsoft.Testing.Extensions.TrxReport\" \u002F>\n  \u003CPackageReference Include=\"Microsoft.Testing.Extensions.CrashDump\" \u002F>\n  \u003CPackageReference Include=\"Microsoft.Testing.Extensions.HangDump\" \u002F>\n  \u003CPackageReference Include=\"Microsoft.Testing.Extensions.CodeCoverage\" \u002F>\n\u003C\u002FItemGroup>\n```\n\nAdd matching `PackageVersion` entries in `Directory.Packages.props`. Without\nCentral Package Management, put exact versions resolved from the configured\nfeed on these references. Keep the versions compatible with the selected MTP\nstack; do not copy fixed versions from migration guidance.\n\n### Step 7: Update CI\u002FCD pipelines\n\n#### Azure DevOps\n\n**If using the VSTest task (`VSTest@3`)**: Replace with the .NET Core CLI task (`DotNetCoreCLI@2`):\n\n```yaml\n# Before (VSTest task)\n- task: VSTest@3\n  inputs:\n    testAssemblyVer2: '**\u002F*Tests.dll'\n    runSettingsFile: 'test.runsettings'\n\n# After (.NET Core CLI task)\n- task: DotNetCoreCLI@2\n  displayName: Run tests\n  inputs:\n    command: 'test'\n    arguments: '--no-build --configuration Release'\n```\n\n**If already using DotNetCoreCLI@2**: Update arguments per Step 5 translations. Remember the `--` separator on .NET 9 and earlier:\n\n```yaml\n- task: DotNetCoreCLI@2\n  displayName: Run tests\n  inputs:\n    command: 'test'\n    arguments: '--no-build -- --report-trx --results-directory $(Agent.TempDirectory)'\n```\n\n#### GitHub Actions\n\nUpdate `dotnet test` invocations in workflow files with the same argument translations from Step 5.\n\n#### Replace vstest.console.exe\n\nIf any script invokes `vstest.console.exe` directly, replace it with `dotnet test`. The test projects are now executables and can also be run directly.\n\n### Step 8: Handle behavioral differences\n\n#### Zero tests exit code\n\nVSTest silently succeeds when zero tests are discovered. MTP fails with **exit code 8**. Options:\n\n- Pass `--ignore-exit-code 8` when running tests\n- Add to `Directory.Build.props`:\n\n```xml\n\u003CPropertyGroup>\n  \u003CTestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8\u003C\u002FTestingPlatformCommandLineArguments>\n\u003C\u002FPropertyGroup>\n```\n\n- Use environment variable: `TESTINGPLATFORM_EXITCODE_IGNORE=8`\n\n### Step 9: Remove VSTest-only packages (optional)\n\nOnce migration is complete and verified, remove packages that are only needed for VSTest:\n\n- `Microsoft.NET.Test.Sdk` -- not needed for MTP (MSTest.Sdk v4 already omits it by default)\n- `xunit.runner.visualstudio` -- only needed for VSTest discovery of xUnit.net (not needed when using `YTest.MTP.XUnit2`)\n- `NUnit3TestAdapter` VSTest-only features -- the adapter is still needed but only for the MTP runner\n\n> **Note**: If you need to maintain VSTest compatibility during a transition period, keep these packages.\n\n### Step 10: Verify\n\n1. Run `dotnet build` -- confirm zero errors\n2. Run `dotnet test` -- confirm all tests pass\n3. Compare test pass\u002Ffail counts to the pre-migration baseline\n4. Run the test executable directly (e.g., `.\u002Fbin\u002FDebug\u002Fnet8.0\u002FMyTests.exe`) -- confirm it works\n5. Verify CI pipeline produces the expected test result artifacts (TRX files, code coverage, crash dumps)\n6. Test that Test Explorer in Visual Studio (17.14+) or VS Code discovers and runs tests\n\n## Validation\n\n- [ ] All test projects use MTP runner (no VSTest-only configuration remains)\n- [ ] `dotnet build` completes with zero errors\n- [ ] `dotnet test` passes all tests and test counts match pre-migration baseline\n- [ ] Test executable runs directly (e.g., `.\u002Fbin\u002FDebug\u002Fnet8.0\u002FMyTests.exe`)\n- [ ] CI pipeline produces expected test result artifacts (TRX files, code coverage, crash dumps)\n- [ ] Test Explorer in Visual Studio or VS Code discovers and runs tests\n- [ ] No `vstest.console.exe` invocations remain in CI scripts\n- [ ] `\u003COutputType>Exe\u003C\u002FOutputType>` is set for all non-MSTest.Sdk test projects\n\n## Common Pitfalls\n\n| Pitfall | Solution |\n|---------|----------|\n| Mixing VSTest and MTP projects in the same solution | Migrate all test projects together -- mixed mode is unsupported |\n| `dotnet test` arguments ignored on .NET 9 and earlier | Use `--` to separate build args from MTP args: `dotnet test -- --report-trx` |\n| Exit code 8 on CI without failures | MTP fails when zero tests run; use `--ignore-exit-code 8` or fix test discovery |\n| MSTest.Sdk v4 + vstest.console no longer works | MSTest.Sdk v4 no longer adds `Microsoft.NET.Test.Sdk` -- add it explicitly or switch to `dotnet test` |\n| Missing `\u003COutputType>Exe\u003C\u002FOutputType>` | Required for all setups except MSTest.Sdk (which sets it automatically) |\n| Using `Condition=\"'$(IsTestProject)' == 'true'\"` in `Directory.Build.props` | `IsTestProject` is not yet defined when `Directory.Build.props` is evaluated -- use `$(MSBuildProjectName.EndsWith('.Tests'))` (or a similar name-based check) instead |\n\n## Next Steps\n\n- Use `run-tests` for running tests on the new MTP platform\n- Use `mtp-hot-reload` for iterative test fixing with hot reload on MTP\n\n## More Info\n\n- [Test platforms overview](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Ftest-platforms-overview)\n- [Migrate from VSTest to Microsoft.Testing.Platform](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Fmigrating-vstest-microsoft-testing-platform)\n- [Microsoft.Testing.Platform overview](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Fmicrosoft-testing-platform-intro)\n- [Testing with dotnet test](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Funit-testing-with-dotnet-test)\n- [Microsoft.Testing.Platform CLI options](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Fmicrosoft-testing-platform-cli-options)\n- [Microsoft.Testing.Platform extensions](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Ftesting\u002Funit-testing-platform-extensions)\n",{"name":5,"license":15,"description":57},"Use this skill before answering, planning, or editing whenever .NET tests or CI are switching from VSTest to Microsoft.Testing.Platform (MTP), or an MTP migration behaves differently. Triggers include \"switch from VSTest\"; MSTest\u002FNUnit\u002FxUnit MTP enablement; OutputType=Exe only for test projects in Directory.Build.props; EnableMSTestRunner, EnableNUnitRunner, UseMicrosoftTestingPlatformRunner, or YTest.MTP.XUnit2; .NET 10 global.json test.runner and TestingPlatformDotnetTestSupport; translating VSTest filters, logger, coverage, blame, or dump arguments; replacing VSTest@3; and exit code 8 or zero tests. Also use for xUnit v3 MTP filters during a v2-to-v3 upgrade. Do not use for framework conversion, TFM, UWP, or WinUI.\n","main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","catalog\u002FTesting\u002FOfficial-DotNet-Test-Migration\u002Fskills\u002Fmigrate-vstest-to-mtp",41,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills","https:\u002F\u002Fskills.managed-code.com","https:\u002F\u002Fgithub.com\u002Fmanagedcode","https:\u002F\u002Fwww.managed-code.com","Open Source Community for .NET Developers: Reliable, Actively Maintained, and Community-Driven. Made in Ukraine 🇺🇦 with ❤️","2026-11-12 19:59:36",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add managedcode\u002Fdotnet-skills --skill migrate-vstest-to-mtp",{"tool":74,"command":75},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill migrate-vstest-to-mtp",{"tool":77,"command":78},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill migrate-vstest-to-mtp","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTesting\u002FOfficial-DotNet-Test-Migration\u002Fskills\u002Fmigrate-vstest-to-mtp\u002FSKILL.md",true,[82,88],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"index.json","REFERENCE","参考文档",670,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fsoc\u002Fhunting\u002Fcloud\u002Fanalyze\u002Findex.json",{"path":89,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":90,"sourceHtmlUrl":91},"manifest.json",178,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTesting\u002FOfficial-DotNet-Test-Migration\u002Fskills\u002Fmigrate-vstest-to-mtp\u002Fmanifest.json",[93,127,151,181,191,217],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":107,"publishedAt":52},"01M6DYQE1Y9FHAQHEDTVFQ3447","xtwitter-scraper","Use XTwitterScraper when a .NET application needs typed access to Xquik's X automation REST API for tweet search, user lookup, posting workflows, extraction jobs, monitors, webhooks, or giveaway draws. USE FOR: integrating the XTwitterScraper NuGet package; reviewing Xquik API client usage; modeling API-key configuration, pagination, binary exports, raw responses, retries, and webhook\u002Fevent flows in .NET. DO NOT USE FOR: unrelated stacks; direct browser automation; generic social-media strategy; or code that does not call Xquik. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FXTwitterScraper\u002Fskills\u002Fxtwitter-scraper\u002FSKILL.md",[99,102],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[108,109,110,111,50,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126],"xtwitter scraper","browser automation","workflows","run","browser","search","repository","api","Media","api client","access","edit","unrelated","webhooks","files","social","commands","modeling","webhook",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":139,"publishedAt":52},"01M6DYQ9S4PE1H6G8MCH9T21HR","sep","Use Sep for high-performance separated-value parsing and writing in .NET, including delimiter inference, explicit parser\u002Fwriter options, and low-allocation row\u002Fcolumn workflows. USE FOR: delimited data needs are performance-sensitive and allocation-aware; project needs explicit control over separator inference, escaping, trimming, and header behavior;. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FSep\u002Fskills\u002Fsep\u002FSKILL.md",[133,136],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":137,"categoryName":138,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000036","内容创作者",[129,140,141,110,142,111,114,143,144,145,119,146,120,122,37,147,148,149,124,150],"writing","performance","tasks","data","parsing","parser","context","writer","options","project","high-performance",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":52},"01M6DZS2DNEPXCGGF6SSCW6G5V","webgpu-threejs-tsl","Comprehensive guide for developing WebGPU-enabled Three.js applications using TSL (Three.js Shading Language). Covers WebGPU renderer setup, TSL syntax and node materials, compute shaders, post-processing effects, and WGSL integration. Use this skill when working with Three.js WebGPU, TSL shaders, node materials, or GPU compute in Three.js.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fwebgpu-claude-skill\u002Fskills\u002Fwebgpu-threejs-tsl\u002FSKILL.md",[],[158,159,160,161,162,163,164,165,166,167,168,169,43,170,171,172,173,174,175,176,28,177,178,179,180],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","node","syntax","guide","language","three","compute","post","processing","with","renderer","materials","wgsl","effects","when",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":52},"01M6DZS0BQXW2B56A289XF1X76","roslynk","Use Roslynk for semantic inspection and edits of *.cs, *.razor and *.cshtml solution files.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Froslynk\u002Fskills\u002Froslynk\u002FSKILL.md",[],[183,43,122,188,189,28,190],"semantic","razor","inspection",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":52},"01M6DZRW6MEJCVW80K3S4XV60K","system-text-json-net11","Imperative guidance for the System.Text.Json APIs added in .NET 11: the built-in `JsonNamingPolicy.PascalCase` naming policy, and the strongly-typed generic `JsonSerializerOptions.GetTypeInfo` and `JsonSerializerOptions.TryGetTypeInfo` metadata accessors (generic overloads that return a typed `JsonTypeInfo`). USE ONLY when the user is targeting net11.0 or later and needs PascalCase JSON property or dictionary-key names without writing a custom naming policy, a strongly-typed generic `JsonTypeInfo` instead of the non-generic `JsonTypeInfo`, or a no-throw way to probe whether a type's serialization metadata is resolved. DO NOT USE when the target is earlier than net11.0, the requested behavior uses an established pre-net11 naming policy, or the user explicitly selected another JSON library.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fsystem-text-json-net11\u002FSKILL.md",[],[198,199,200,201,140,202,203,204,205,206,207,43,42,208,209,210,37,211,212,213,214,28,215,216,180],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":225,"publishedAt":52},"01M6DZRRJP3S662NFSG1RSPQQ7","process-api-net11","Provides guidance on the new System.Diagnostics.Process APIs introduced in .NET 11: Process.Run, Process.RunAndCaptureText, Process.StartAndForget, Process.ReadAllText\u002FBytes\u002FLines, KillOnParentExit, InheritedHandles, and StartDetached. USE FOR: starting, orchestrating, or capturing output from external processes in applications targeting net11.0 or later. DO NOT USE FOR: applications targeting .NET 10 or earlier, or basic pre-.NET 11 Process.Start usage without new APIs.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fprocess-api-net11\u002FSKILL.md",[223,224],{"categoryNo":100,"categoryName":101,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},[115,226,227,228,111,229,165,198,43,209,210,37,230,231,232,233,214,28,234],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]