migrate-mstest-v1v2-to-v3

What it does

Guides and executes migration of MSTest v1/v2 projects to MSTest v3, addressing breaking changes that surface after upgrading packages. It covers removing v1 assembly references, updating to MSTest v3 (including MSTest metapackage or MSTest.Sdk options), preserving or updating the test runner, and adapting to Breaking Changes Summary (notably assertion overloads, DataRow typing, and .testsettings to .runsettings). It includes steps to verify package versions, adjust target frameworks, and fix only the applicable breaking changes present in the project. It emphasizes assessing current MSTest version, preserving test platforms, and performing full migrations when requested. It provides concrete fix guidance for assertion overloads and DataRow literal typing, and warns to delete legacy settings files when required.

How it works

1. Assess the project to determine whether MSTest v1 via assembly reference or MSTest v1/v2 via NuGet 1.x/2.x is in use.
2. If MSTest v1 assembly reference is present, remove the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll reference from the .csproj (SDK-style) or via Visual Studio references, then save.
3. Update packages to MSTest v3 by replacing individual MSTest.* references with the MSTest metapackage (Include="MSTest" Version="3.8.0"). Ensure Microsoft.NET.Test.Sdk is updated to a compatible version (e.g., 17.13.0 or later) unless centrally managed. If using MSTest.Sdk, adjust the project to MSTest.Sdk/3.8.0 and remove obsolete MSTest-related packages and properties as indicated.
4. Update target frameworks as needed to supported TFMs (e.g., net6.0+/net8.0, netstandard2.0, etc.) per the Breaking Changes Summary.
5. Resolve build errors by applying only the relevant changes listed in the Breaking Changes Summary: fix Assert.AreEqual/AreNotEqual/AreSame calls by adding explicit type arguments when inference fails; fix DataRow literal types to exact parameter types (e.g., 1 vs 1L); and delete .testsettings in favor of .runsettings with equivalent configuration. Do not modify beyond the discovered issues.
6. Run the existing test command and verify results, updating as needed based on the project’s evidence.

When to use it

• When the project references Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll (MSTest v1) or uses MSTest.TestFramework/TestAdapter NuGet 1.x/2.x and needs migration to MSTest v3.
• When resolving build errors after updating MSTest packages to v3, including scenarios where packages show 3.x but legacy settings or code still require fixes.
• When converting .testsettings to .runsettings and adopting MSTest.Sdk vs MSTest metapackage.

What it can touch

• Project file edits to remove v1 assembly references or adjust PackageReference blocks.
• NuGet package references: MSTest, MSTest.TestFramework, MSTest.TestAdapter, MSTest.Sdk, Microsoft.NET.Test.Sdk, and related configuration properties.
• Source files that contain breaking-change usage such as Assert.AreEqual/AreNotEqual/AreSame calls and DataRow literals.
• Configuration files: .testsettings (to be replaced by .runsettings) and related deployment/configuration settings.
• Target framework declarations in the project as needed to align with MSTest v3 support.

Caveats

• MSTest v3 is not binary compatible with v1/v2; libraries must be recompiled against v3.
• If a project already uses MSTest v3 with no leftover v1/v2 items, this skill reports migration as complete and makes no changes.
• The tool requires evidence from the project to decide which path to take (assembly reference vs NuGet) and does not proceed with speculative edits.
• The summary emphasizes concrete fixes only for issues observed in the project (e.g., type-argument fixes for Assert.AreEqual, DataRow type matching), and avoids broad, unconditional changes.