/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.
$ npx -y skills add managedcode/dotnet-skills --skill platform-detection --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/platform-detection
Context preview
The summary Claude sees to decide when to auto-load this skill.
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.
SKILL.md
platform-detection.SKILL.mdname: platform-detection
description: "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."
user-invocable: false
disable-model-invocation: true
license: MIT
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` → `.csproj` → `Directory.Build.props` → `Directory.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.
Read more
name: platform-detection description: "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." user-invocable: false disable-model-invocation: true license: MIT
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` → `.csproj` → `Directory.Build.props` → `Directory.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.
Stop explaining .NET to your AI. Start building. We've all been there: asking Claude to use Entity Framework, only to get EF6 patterns in a .NET 8 project. Explaining to Copilot that Blazor Server and Blazor WebAssembly aren't the same thing.
Repo: managedcode/dotnet-skills
Other skills on dotnet-skills.
- /aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET. USE FOR: working on ASP.NET Core apps, services, or middleware; changing auth, routing, configuration,
Open skill - /aspire
Build, upgrade, and operate Aspire 13.4.x C# or TypeScript application hosts with the current CLI, AppHost, ServiceDefaults, integrations, dashboard, testing, MCP, and deployment patterns for distributed apps. USE FOR: Aspire.AppHost.Sdk, Aspire.Hosting.*,
Open skill - /azure-functions
Build, review, or migrate Azure Functions in .NET with correct execution model, isolated worker setup, bindings, DI, and Durable Functions patterns. USE FOR: working on Azure Functions in .NET; migrating from the in-process model to the isolated worker model; adding Durable
Open skill - /blazor
Build and review Blazor applications across server, WebAssembly, web app, and hybrid scenarios with correct component design, state flow, rendering, and hosting choices. USE FOR: building interactive web UIs with C# instead of JavaScript; choosing between Server, WebAssembly, or
Open skill - /entity-framework6
Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. USE FOR: EF6 codebases; runtime versus ORM migration decisions; EDMX, code-first, ObjectContext, and legacy data-access
Open skill - /entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications. USE FOR: DbContext, migrations, model configuration, EF queries, tracking, loading, performance, transactions, and
Open skill

