/migrate-mstest-v3-to-v4

name: migrate-mstest-v3-to-v4
description: >
  Fix build errors and breaking changes after upgrading MSTest v3 to v4, or
  plan a complete v3-to-v4 migration. Use when user says "upgrade to
  MSTest v4", "MSTest 4 migration", "MSTest v4 breaking changes", "tests don't
  compile after upgrading MSTest 3.x to 4.x", or hits CS0507, CS0103, CS1061, CS1615 after updating MSTest packages to 4.x.
  USE FOR: Execute to ExecuteAsync, CallerInfo ctor on TestMethodAttribute,
  sealed custom attributes, ClassCleanupBehavior removal, TestContext.Properties
  Contains to ContainsKey, Assert.ThrowsException to ThrowsExactly,
  Assert.IsInstanceOfType out param removal, ExpectedExceptionAttribute
  removal, TestTimeout enum removal, [TestMethod("name")] to DisplayName syntax,
  TreatDiscoveryWarningsAsErrors, TestContext.TestName in ClassInitialize,
  MSTest.Sdk MTP changes, dropped TFMs (net6.0/net7.0 to net8.0+).
  DO NOT USE FOR: MSTest v1/v2 to v3, or errors left from a 2.x-to-3.x upgrade
  (use migrate-mstest-v1v2-to-v3 first); test framework conversions; general
  .NET upgrades.
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.

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 |

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.
• **Focused fix requests** (user has specific compilation errors after upgrading): Address only the relevant breaking changes from Step 3. **Always provide concrete fixed code** using the user's actual types and method names — show a complete, copy-pasteable code snippet, not just a description of what to change. 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). 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 defaults to MTP mode, which does not include Microsoft.NET.Test.Sdk -- needed for vstest.console) and 4.4 (TreatDiscoveryWarningsAsErrors). Explain the root cause clearly and give both fix options (add Microsoft.NET.Test.Sdk package or switch to `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.

Workflow

> **Commit strategy:** Commit at each logical boundary -- after updating packages (Step 2), after resolving source breaking changes (Step 3), after addressing behavioral changes (Step 4). This keeps each commit focused and reviewable.

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-wi