Github Copilot generated skill to update a test project to use MsTest.Sdk

SKILL.md

name	migrating-to-mstest-sdk
description	Migrates .NET test projects from the traditional MSTest setup (Microsoft.NET.Test.Sdk + MSTest.TestAdapter + MSTest.TestFramework) to MSTest.Sdk, the modern project SDK approach that bundles all testing infrastructure. Use when upgrading test projects, modernizing MSTest configuration, adopting MSTest Platform (MTP), or when users ask to "switch to MSTest.Sdk", "use latest MSTest", "migrate to MTP", or "update test project to MSTest SDK". Also relevant during .NET version upgrades when test projects are being modernized.
metadata	traits discovery test|mstest|sdk|migration|dotnet lazy

Migrating to MSTest.Sdk

Migrate .NET test projects from the traditional package-based MSTest setup to MSTest.Sdk, a modern project SDK that consolidates testing infrastructure and provides Microsoft Testing Platform (MTP) capabilities.

What Changes

Before (Traditional):

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.*" />
    <PackageReference Include="MSTest.TestAdapter" Version="3.*" />
    <PackageReference Include="MSTest.TestFramework" Version="3.*" />
  </ItemGroup>
</Project>

After (MSTest.Sdk):

<Project Sdk="MSTest.Sdk/4.3.3">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
  <!-- MSTest packages now included in SDK -->
</Project>

What MSTest.Sdk Provides

The SDK automatically includes:

• MSTest.TestAdapter (same version as SDK)
• MSTest.TestFramework (same version as SDK)
• Microsoft.Testing.Extensions.CodeCoverage (latest compatible)
• Microsoft.Testing.Extensions.TrxReport (latest compatible)

You no longer need to reference these packages explicitly.

Migration Process

Step 1: Verify MSTest.Sdk Availability

Before migrating, confirm the SDK is accessible from your package sources:

# Test by creating a temporary project
dotnet new console -n TempTest -o C:\temp\mstestcheck
# Try adding MSTest.Sdk as a package to verify it's available
dotnet add C:\temp\mstestcheck\TempTest.csproj package MSTest.Sdk

If the package resolves successfully, you can proceed. As of 2025, the current stable version is 4.3.3.

Version note: Check for newer versions on NuGet.org or your organization's package feed. The SDK version should match or exceed your current MSTest package versions.

Step 2: Back Up the Project File

Before making changes, capture the current state:

Copy-Item MyTestProject.csproj MyTestProject.csproj.backup

This allows easy rollback if issues arise.

Step 3: Update the Project SDK Attribute

Change the Sdk attribute from Microsoft.NET.Sdk to MSTest.Sdk/{version}:

<Project Sdk="MSTest.Sdk/4.3.3">

The version in the SDK attribute pins the MSTest infrastructure to that specific release.

Step 4: Remove Redundant Packages

Delete these package references (they're now included in the SDK):

• Microsoft.NET.Test.Sdk
• MSTest.TestAdapter
• MSTest.TestFramework

Keep all other packages (test utilities, mocking frameworks, assertion libraries, application dependencies).

Step 5: Handle Multi-Targeting

If your test project multi-targets (e.g., <TargetFrameworks>net8.0;net10.0</TargetFrameworks>):

1. Change <TargetFramework> (singular) to <TargetFrameworks> (plural)
2. MSTest.Sdk works across all target frameworks without conditional logic
3. No framework-specific package references needed for the MSTest stack itself

Example:

<Project Sdk="MSTest.Sdk/4.3.3">
  <PropertyGroup>
    <TargetFrameworks>net8.0;net10.0</TargetFrameworks>
  </PropertyGroup>
</Project>

Step 6: Clean and Restore

Remove built artifacts to ensure a clean slate:

Remove-Item obj -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item bin -Recurse -Force -ErrorAction SilentlyContinue
dotnet restore MyTestProject.csproj

Step 7: Build and Verify

dotnet build MyTestProject.csproj

Expected outcome: Clean build for all target frameworks with no errors.

Step 8: Check Package Listings

Verify what the SDK brought in:

dotnet list MyTestProject.csproj package

You should see MSTest.TestAdapter, MSTest.TestFramework, and testing extensions listed as dependencies, even though you didn't explicitly reference them.

Step 9: Run Tests

dotnet test MyTestProject.csproj

All existing tests should pass without code changes. MSTest.Sdk is backward compatible with traditional MSTest test code.

Common Issues and Resolutions

Issue: Package Downgrade Warnings (NU1605)

Symptom:

error NU1605: Detected package downgrade: System.Security.Cryptography.Xml from 9.0.15 to 8.0.4

Cause: Transitive dependencies from your application packages may conflict with versions preferred by MSTest.Sdk.

Resolution: Add an explicit package reference for the higher version:

<ItemGroup>
  <!-- Resolve version conflict by pinning to the newer version -->
  <PackageReference Include="System.Security.Cryptography.Xml" Version="9.*" />
</ItemGroup>

Replace System.Security.Cryptography.Xml with the actual conflicting package from your error message.

Issue: NETSDK1005 - Assets File Missing Target

Symptom:

NETSDK1005: Assets file 'obj\project.assets.json' doesn't have a target for 'netX.0'

Cause: Stale obj folder from the previous SDK configuration.

Resolution:

Remove-Item obj -Recurse -Force
Remove-Item bin -Recurse -Force
dotnet restore
dotnet build

Always clean before building after SDK changes.

Issue: Test Discovery Fails

Symptom: dotnet test reports zero tests found, but the test methods exist.

Cause: Rare compatibility issue with custom test adapters or third-party test frameworks.

Resolution:

1. Verify [TestClass] and [TestMethod] attributes are present
2. Check for conflicting test framework packages (xUnit, NUnit) in the same project
3. Ensure test classes are public
4. Try explicit restore: dotnet restore --force

Issue: MSTest.Sdk Not Found

Symptom: NuGet can't resolve MSTest.Sdk during restore.

Cause: Your package source doesn't include MSTest.Sdk.

Resolution:

1. Verify you have access to NuGet.org or a mirror that includes Microsoft packages
2. Check your nuget.config for restricted sources
3. Temporarily test with NuGet.org directly: dotnet restore --source https://api.nuget.org/v3/index.json

Multi-Targeting with Framework-Specific Packages

When test projects multi-target and some application dependencies need different versions per framework, use conditional item groups:

<Project Sdk="MSTest.Sdk/4.3.3">
  <PropertyGroup>
    <TargetFrameworks>net8.0;net10.0</TargetFrameworks>
  </PropertyGroup>

  <!-- Shared packages (work for all TFMs) -->
  <ItemGroup>
    <PackageReference Include="Moq" Version="4.*" />
    <PackageReference Include="FluentAssertions" Version="6.*" />
  </ItemGroup>

  <!-- .NET 8 specific packages -->
  <ItemGroup Condition="'$(TargetFramework)' == 'net8.0'">
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="8.*" />
  </ItemGroup>

  <!-- .NET 10 specific packages -->
  <ItemGroup Condition="'$(TargetFramework)' == 'net10.0'">
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="10.*" />
  </ItemGroup>
</Project>

This pattern is useful when:

• Testing libraries that target a specific runtime version
• Application packages tied to framework versions (e.g., ASP.NET Core)
• Packages with breaking changes between major .NET versions

When NOT to Migrate

Skip migration if:

1. Pinned to older MSTest versions - Your team explicitly requires MSTest 2.x for compatibility reasons
2. Custom test adapters conflicting - You use proprietary test runners incompatible with MTP
3. Legacy .NET Framework-only projects - MSTest.Sdk targets .NET Core/5+ scenarios; stick with packages for .NET Framework 4.x
4. Corporate policy restrictions - Organization mandates package-based approach for auditing

Validation Checklist

After migration, verify:

• Project builds without warnings
• All target frameworks restore successfully
• dotnet test discovers all tests
• Test execution passes (same results as before)
• Code coverage collection works (if used)
• CI/CD pipelines complete successfully
• No package downgrade warnings (NU1605)

Benefits of MSTest.Sdk

• Fewer package references - Three packages become one SDK declaration
• Version alignment - MSTest packages automatically stay in sync
• Microsoft Testing Platform - Built-in support for modern testing features
• Simplified maintenance - SDK version updates are centralized
• Multi-targeting friendly - No need to duplicate package references per TFM

Related Skills

Related skill: managing-target-frameworks - Covers multi-targeting in depth Related skill: dotnet-version-upgrade - Often triggers test project modernization