.github/skills/platform-detection/SKILL.md
Reference data for detecting the test platform (VSTest vs Microsoft.Testing.Platform) and test framework (MSTest, xUnit, NUnit, TUnit) from project files. DO NOT USE directly — loaded by run-tests, mtp-hot-reload, and migrate-vstest-to-mtp when they need detection logic.
npx skillsauth add microsoft/vstest platform-detectionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Determine which test platform (VSTest or Microsoft.Testing.Platform) and which test framework (MSTest, xUnit, NUnit, TUnit) a project uses.
Detection files to always check (in order): global.json → .csproj → Directory.Build.props → Directory.Packages.props
Read the .csproj file and Directory.Build.props / Directory.Packages.props (for centrally managed dependencies) and look for:
| Package or SDK reference | Framework |
|--------------------------|-----------|
| MSTest (metapackage, recommended) or <Sdk Name="MSTest.Sdk"> | MSTest |
| MSTest.TestFramework + MSTest.TestAdapter | MSTest (also valid for v3/v4) |
| xunit, xunit.v3, xunit.v3.mtp-v1, xunit.v3.mtp-v2, xunit.v3.core.mtp-v1, xunit.v3.core.mtp-v2 | xUnit |
| NUnit + NUnit3TestAdapter | NUnit |
| TUnit | TUnit (MTP only) |
The detection logic depends on the .NET SDK version. Run dotnet --version to determine it.
On .NET 10+, the global.json test.runner setting is the authoritative source:
global.json contains "test": { "runner": "Microsoft.Testing.Platform" } → MTPglobal.json has "runner": "VSTest", or no test section exists → VSTestImportant: On .NET 10+,
<TestingPlatformDotnetTestSupport>alone does not switch to MTP. Theglobal.jsonrunner setting takes precedence. If the runner is VSTest (or unset), the project uses VSTest regardless ofTestingPlatformDotnetTestSupport.
On older SDKs, check these signals in priority order:
1. Check the <TestingPlatformDotnetTestSupport> MSBuild property. Look in the .csproj, Directory.Build.props, and Directory.Packages.props. If set to true in any of these files, the project uses MTP.
Critical: Always read
Directory.Build.propsandDirectory.Packages.propsif they exist. MTP properties are frequently set there instead of in the.csproj, so checking only the project file will miss them.
2. Check project-level signals:
| Signal | Platform |
|--------|----------|
| <Sdk Name="MSTest.Sdk"> as project SDK | MTP by default |
| <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> | MTP runner (xUnit) |
| <EnableMSTestRunner>true</EnableMSTestRunner> | MTP runner (MSTest) |
| <EnableNUnitRunner>true</EnableNUnitRunner> | MTP runner (NUnit) |
| Microsoft.Testing.Platform package referenced directly | MTP |
| TUnit package referenced | MTP (TUnit is MTP-only) |
Note: The presence of
Microsoft.NET.Test.Sdkdoes not necessarily mean VSTest. Some frameworks (e.g., MSTest) pull it in transitively for compatibility, even when MTP is enabled. Do not use this package as a signal on its own — always check the MTP signals above first. Key distinction: VSTest is the classic platform that usesvstest.consoleunder the hood. Microsoft.Testing.Platform (MTP) is the newer, faster platform. Both can be invoked viadotnet test, but their filter syntax and CLI options differ.
development
Best practices for writing MSTest 3.x/4.x unit tests. Use when the user needs to write, improve, fix, or review MSTest tests, including modern assertions, data-driven tests, test lifecycle, and common anti-patterns. Also use when fixing test issues like swapped Assert.AreEqual arguments, incorrect assertion usage, or modernizing legacy test code. Covers MSTest.Sdk, sealed classes, Assert.Throws, DynamicData with ValueTuples, TestContext, and conditional execution.
development
Build, test, and validate changes in the vstest repository. Use when building vstest projects, running unit tests, smoke tests, or acceptance tests, or when deploying locally built vstest.console for manual testing.
development
Validate that commands documented in skill files actually work. Use when creating, updating, or reviewing skills to ensure all documented commands exit with code 0.
testing
Parse and analyze Visual Studio TRX test result files. Use when asked about slow tests, test durations, test frequency, flaky tests, failure analysis, or test execution patterns from TRX files.