---

name: migrate-mstest-v3-to-v4 description: > Use this skill before answering, planning, or editing any MSTest 3.x-to-4.x upgrade or post-upgrade failure. Triggers include "MSTest v4 breaking changes"; CS0507/CS0103/CS1061/CS1615; ExecuteAsync, CallerInfo, DisplayName, or custom TestMethodAttribute; ClassCleanupBehavior; ContainsKey; ThrowsExactly or ExpectedException; IsInstanceOfType out parameters; TestTimeout.Infinite; ManagedType; net6/net7 compatibility; TestCase.Id history; TestName in ClassInitialize; TreatDiscoveryWarningsAsErrors; discovery errors after a clean build; and MSTest.Sdk/MTP or vstest.console discovery changes. Do not use for v1/v2-to-v3 leftovers, framework conversion, runner-only migration, or a general .NET upgrade. license: MIT

MSTest v3 -> v4 Migration

Migrate a test project from MSTest v3 to MSTest v4. The outcome is a project using MSTest v4 that builds cleanly, passes tests, and accounts for every source-incompatible and behavioral change. MSTest v4 is not binary compatible with MSTest v3 -- any library compiled against v3 must be recompiled against v4.

First Action

Inspect the supplied project and source before searching the web or answering from memory. Classify the request as a focused source fix, runtime behavior change, CI discovery issue, compatibility question, or full migration, then follow the matching row below. A clean compile does not exclude this skill: discovery failures, TestContext lifecycle exceptions, and test-history changes are runtime migration failures.

When to Use

• Upgrading MSTest.TestFramework, MSTest.TestAdapter, or MSTest metapackage from 3.x to 4.x
• Upgrading MSTest.Sdk from 3.x to 4.x
• Fixing build errors after updating to MSTest v4 packages
• Resolving behavioral changes in test execution after upgrading to MSTest v4
• Updating custom TestMethodAttribute or ConditionBaseAttribute implementations for v4

When Not to Use

• The project already uses MSTest v4 and builds cleanly -- migration is done
• Upgrading from MSTest v1 or v2 -- use migrate-mstest-v1v2-to-v3 first, then return here
• The project does not use MSTest
• Migrating between test frameworks (e.g., MSTest to xUnit or NUnit)

Inputs

| Input | Required | Description | |-------|----------|-------------| | Project or solution path | No | The .csproj, .sln, or .slnx entry point containing MSTest test projects. Discover it yourself by globbing the working directory; ask only when nothing is found or the choice is genuinely ambiguous | | Build command | No | How to build (e.g., dotnet build, a repo build script). Auto-detect if not provided | | Test command | No | How to run tests (e.g., dotnet test). Auto-detect if not provided |

Decisions That Change the Result

| Detected request or state | Required action | |---|---| | Files are supplied in the current workspace | Search there and open the literal returned paths. The skill directory is not the project directory. If one tool rejects a valid path, retry with another available reader/editor; do not ask the user for a path you can discover. | | User asks to apply changes to supplied files: "fix my project/files", "please update this source", "make the changes", or "then build and run" | Edit every affected occurrence. Run the narrowest meaningful build/test command against the actual package version; skill activation is not a reason to stop at advice. | | User asks "what should I expect?", "how do I fix these changes?", for compatibility advice, or for a plan | Answer directly from the actual project state even when source is visible. Keep a single-symptom answer focused; include only adjacent risks that change the decision. | | Unsupported TFM in a full migration | Update the TFM first, then update MSTest packages, then fix source breaks. Do not bury this order in a release-note inventory. | | Custom TestMethodAttribute subclass | Treat ExecuteAsync, CallerInfo propagation, display-name handling, and the subclass's retry/result semantics as one coupled migration. Fix the actual class, not a placeholder example. | | MSTest.Sdk v4 source/API errors (ManagedType, TestTimeout, Contains) | Give the exact source replacements, then add the adjacent runner warning: MTP mode no longer supplies Microsoft.NET.Test.Sdk; add it only if VSTest discovery is still required. | | MSTest.Sdk v4 plus vstest.console | This is a v4 change: MTP mode no longer brings Microsoft.NET.Test.Sdk. Keep MTP and add that package for transitional VSTest discovery, opt into UseVSTest, or migrate CI to dotnet test; state which runner the choice preserves. |

Response Guidelines

• Always identify the current version first: Before recommending any migration steps, explicitly state the current MSTest version detected in the project (e.g., "Your project uses MSTest v3 (3.8.0)"). This confirms you've read the project files and grounds the migration advice.
• Resolve, do not assume, the target version: When the user asks for "latest", query the project's configured package source and select the latest stable MSTest v4 version available at execution time. Never copy the example version from this skill into the result without checking it. Keep all MSTest packages on the same resolved version.
• Focused fix requests (user has specific compilation errors after upgrading): Address only the relevant breaking changes from Step 3. Make edits only when the requested deliverable is a source change; "how do I fix these?" remains an answer request. Always provide concrete fixed code using the user's actual types and method names. If the fixture still references v3, do not claim that a green v3 build verifies v4 compatibility; either update packages when requested or state the verification boundary. For custom TestMethodAttribute subclasses, show the full fixed class including CallerInfo propagation to the base constructor. Mention any related analyzer that could have caught this earlier (e.g., MSTEST0006 for ExpectedException). When the project uses MSTest.Sdk, also state that v4 MTP mode no longer supplies Microsoft.NET.Test.Sdk and whether that affects the visible runner. Do not walk through the entire migration workflow.
• "What to expect" questions (user asks about breaking changes before upgrading): Present ALL major breaking changes from the Step 3 quick-lookup table -- not just the ones visible in the current code. For each, provide a one-line fix summary. Also mention key behavioral changes from Step 4 (especially TestCase.Id history impact and TreatDiscoveryWarningsAsErrors default). If project code is available, highlight which changes apply directly.
• Full migration requests (user wants complete migration): Follow the complete workflow below.
• Behavioral/runtime symptom reports (user describes test execution differences without build errors): Match described symptoms to the behavioral changes table in Step 4. Provide targeted, symptom-specific advice. Mention other behavioral changes the user should watch for. Do not walk through source breaking changes unless the user also has build errors.
• CI/test-discovery issues (tests not discovered, vstest.console stopped working, CI pipeline failures after upgrading): Focus on 4.5 (MSTest.Sdk v4 no longer includes Microsoft.NET.Test.Sdk in its default MTP mode -- it is still needed for vstest.console) and 4.4 (TreatDiscoveryWarningsAsErrors). Explain the root cause clearly and give all three paths: add Microsoft.NET.Test.Sdk while preserving MTP, set UseVSTest to switch the project runner, or switch CI to MTP-native dotnet test. Do not walk through the full migration workflow.
• Explanatory questions (user asks "is this a known change?", "what else should I watch out for?"): Explain the relevant changes and advise. Mention related changes the user might encounter next. Do not prescribe a full migration procedure.
• Result proof: End implementation work with the detected v3 version, resolved v4 version, runner choice, files changed, and actual build/test counts. Never report a build, VSTest compatibility, discovery, or passing tests from inference.

Workflow

Commit strategy: Do not create commits unless the user asks. Keep package, source, and behavioral changes logically separable in the diff, but finish and verify the requested migration.

Step 1: Assess the project

1. Identify the current MSTest version by checking package references for MSTest, MSTest.TestFramework, MSTest.TestAdapter, or MSTest.Sdk in .csproj, Directory.Build.props, or Directory.Packages.props.
2. Confirm the project is on MSTest v3 (3.x). If on v1 or v2, use migrate-mstest-v1v2-to-v3 first.
3. Check target framework(s) -- MSTest v4 drops support for .NET Core 3.1 through .NET 7. Supported target frameworks are: net8.0, net9.0, net462 (.NET Framework 4.6.2+), uap10.0.16299 (UWP), net9.0-windows10.0.17763.0 (modern UWP), and net8.0-windows10.0.18362.0 (WinUI).
4. Check for custom TestMethodAttribute subclasses -- these require changes in v4.
5. Check for usages of ExpectedExceptionAttribute -- removed in v4 (deprecated since v3 with analyzer MSTEST0006).
6. Check for usages of Assert.ThrowsException (deprecated) -- removed in v4.
7. Run a clean build to establish a baseline of existing errors/warnings.

Step 2: Update packages to MSTest v4

First resolve the latest stable v4 version from the configured package source. Pin that exact version consistently in the metapackage, individual packages, MSTest.Sdk, and central package management.

• For the MSTest metapackage, update its PackageReference to the resolved exact version.
• For individual packages, update MSTest.TestFramework and MSTest.TestAdapter to that same version.
• For MSTest.Sdk, update the SDK version in the project or global.json pin to that same version.

Run dotnet restore, then dotnet build. Collect all errors for Step 3.

Step 3: Resolve source breaking changes

Work through compilation errors systematically. Use this quick-lookup table to identify all applicable changes, then apply each fix:

| Error / Pattern in code | Breaking change | Fix | |---|---|---| | Custom TestMethodAttribute overrides Execute | Execute removed | Change to ExecuteAsync returning Task<TestResult[]> (3.1) | | [TestMethod("name")] or custom attribute constructor | CallerInfo params added | Use DisplayName = "name" named param; propagate CallerInfo in subclasses (3.2) | | ClassCleanupBehavior.EndOfClass | Enum removed | Remove argument: just [ClassCleanup] (3.3) | | TestContext.Properties.Contains("key") | Properties is IDictionary<string, object> | Change to ContainsKey("key") (3.4) | | [Timeout(TestTimeout.Infinite)] | TestTimeout enum removed | Replace with [Timeout(int.MaxValue)] (3.5) | | TestContext.ManagedType | Property removed | Use FullyQualifiedTestClassName (3.6) | | Assert.AreEqual(a, b, "msg {0}", arg) | Message+params overloads removed | Use string interpolation: $"msg {arg}" (3.7) | | Assert.ThrowsException<T>(...) | Renamed | Replace with Assert.ThrowsExactly<T>(...) or Assert.Throws<T>(...) (3.7) | | Assert.IsInstanceOfType<T>(obj, out var t) | Out parameter removed | Use var t = Assert.IsInstanceOfType<T>(obj) (3.7) | | [ExpectedException(typeof(T))] | Attribute removed | Move assertion into test body: Assert.ThrowsExactly<T>(() => ...) (3.8) | | Project targets net5.0, net6.0, or net7.0 | TFM dropped | Change to net8.0 or net9.0 (3.9) |

Important: Scan the entire project for ALL patterns above before starting fixes. Multiple breaking changes often coexist in the same project.

3.1 TestMethodAttribute.Execute -> ExecuteAsync

If you have custom TestMethodAttribute subclasses that override Execute, change to ExecuteAsync. This change was made because the