Agent skill

platform-detection

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.

Stars 302
Forks 22

Install this agent skill to your Project

npx add-skill https://github.com/managedcode/dotnet-skills/tree/main/external-sources/upstreams/dotnet-skills/dotnet-test/skills/platform-detection

SKILL.md

Test Platform and Framework Detection

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.csprojDirectory.Build.propsDirectory.Packages.props

Detecting the test framework

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)

Detecting the test platform

The detection logic depends on the .NET SDK version. Run dotnet --version to determine it.

.NET SDK 10+

On .NET 10+, the global.json test.runner setting is the authoritative source:

  • If global.json contains "test": { "runner": "Microsoft.Testing.Platform" }MTP
  • If global.json has "runner": "VSTest", or no test section exists → VSTest

Important: On .NET 10+, <TestingPlatformDotnetTestSupport> alone does not switch to MTP. The global.json runner setting takes precedence. If the runner is VSTest (or unset), the project uses VSTest regardless of TestingPlatformDotnetTestSupport.

.NET SDK 8 or 9

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.props and Directory.Packages.props if 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.Sdk does 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 uses vstest.console under the hood. Microsoft.Testing.Platform (MTP) is the newer, faster platform. Both can be invoked via dotnet test, but their filter syntax and CLI options differ.

Expand your agent's capabilities with these related and highly-rated skills.

managedcode/dotnet-skills

dotnet-project-setup

Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development.

302 22
Explore
managedcode/dotnet-skills

csharp-scripts

Run single-file C# programs as scripts (file-based apps) for quick experimentation, prototyping, and concept testing. Use when the user wants to write and execute a small C# program without creating a full project.

302 22
Explore
managedcode/dotnet-skills

dotnet-pinvoke

Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging existing native interop code, wrapping a C or C++ library for use in .NET, diagnosing crashes, memory leaks, or corruption at the managed/native boundary. DO NOT USE FOR: COM interop, C++/CLI mixed-mode assemblies, or pure managed code with no native dependencies.

302 22
Explore
managedcode/dotnet-skills

nuget-trusted-publishing

Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet/login, secure NuGet publishing. DO NOT USE FOR: publishing to private feeds or Azure Artifacts (OIDC is nuget.org only). INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.

302 22
Explore
managedcode/dotnet-skills

dotnet-legacy-aspnet

Maintain classic ASP.NET applications on .NET Framework, including Web Forms, older MVC, and legacy hosting patterns, while planning realistic modernization boundaries.

302 22
Explore
managedcode/dotnet-skills

dotnet-code-review

Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them.

302 22
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results