/migrate-mstest-v1v2-to-v3

name: migrate-mstest-v1v2-to-v3
description: >
  Migrate MSTest v1/v2 projects to MSTest v3, and fix v1/v2-to-v3 breaking
  changes that surface after the packages are already at 3.x.
  USE FOR: removing v1
  Microsoft.VisualStudio.QualityTools.UnitTestFramework assembly references;
  moving MSTest.TestFramework/TestAdapter 1.x-2.x to 3.x, the MSTest
  metapackage, or MSTest.Sdk; tests that broke after a 2.x-to-3.x bump --
  CS0411/CS1503 on Assert.AreEqual/AreNotEqual/AreSame once the object
  overloads became generic, and DataRow strict type matching (1L vs 1) that
  builds with MSTEST0014 but fails at run time; .testsettings/LegacySettings
  to .runsettings (DeploymentEnabled, per-test MSTest TestTimeout); v3 timeout
  behavior; TFMs v3 dropped (net5.0, .NET Fx below 4.6.2, netstandard1.0).
  Applies even when the project already references MSTest 3.x, if a v1/v2-era
  setting or error remains. Keeps the current runner.
  DO NOT USE FOR: MSTest v4 (use migrate-mstest-v3-to-v4 next), clean v3
  projects with no v1/v2 leftovers, other test frameworks, or VSTest-to-MTP.
license: MIT

MSTest v1/v2 -> v3 Migration

Migrate a test project from MSTest v1 (assembly references) or MSTest v2 (NuGet 1.x-2.x) to MSTest v3. MSTest v3 is **not binary compatible** with v1/v2 -- libraries compiled against v1/v2 must be recompiled.

When to Use

• Project references `Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll` (MSTest v1)
• Project uses `MSTest.TestFramework` / `MSTest.TestAdapter` NuGet 1.x or 2.x
• Resolving build errors after updating MSTest packages from v1/v2 to v3 -- including when the packages already read 3.x and only the source or settings still need fixing
• Replacing `.testsettings` with `.runsettings`
• Adopting MSTest.Sdk or in-assembly parallel execution

When Not to Use

• Project already on MSTest v3 with no migration-related build errors and no leftover `.testsettings` / `<LegacySettings>` (fully migrated)
• Upgrading v3 to v4 -- use `migrate-mstest-v3-to-v4`
• Migrating between frameworks (MSTest to xUnit/NUnit)

Boundary Gate

Check package versions before any edit. If all MSTest references are already 3.x, no v1/v2-to-v3 error is reported, and no `.testsettings` or `<LegacySettings>` remains, state that migration is complete and make no changes. A 3.x package version alone does not end the migration -- leftover v1/v2-era settings files or breaking-change errors are still in scope. Do not consolidate working v3 packages into the metapackage. Run the existing tests only if verification was requested. This overrides all steps below.

Inputs

| Input | Required | Description | |-------|----------|-------------| | Project or solution path | No | The `.csproj`, `.sln`, or `.slnx` entry point. Glob the working directory for it; ask only if nothing is found or several test projects make the target 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 |

> **Never open by asking for the project path.** A user describing their project > in prose is asking a question, not withholding a file -- look on disk first. If > there is genuinely no project file, answer for the setup they described rather > than replying with only a question. > > **Open the paths exactly as the search returned them.** A glob that answers > `./TestProject.csproj` means the file is there, relative to the working > directory -- read it at that path. Do not rebuild it into an absolute path > under this skill's own base directory: that directory holds `SKILL.md`, not the > user's project, so the read fails and the project looks missing when it is not. > If a file you just found fails to open, the path you constructed is wrong -- > retry with the literal result. Never conclude "there is no project on disk" > while a search is still reporting project files, and never scaffold a > substitute project from the prose description as a workaround.

Breaking Changes Summary

MSTest v3 introduces these breaking changes from v1/v2. Address only the ones relevant to the project:

| Breaking Change | Impact | Fix | |---|---|---| | `Assert.AreEqual(object, object)` overload removed; only `AreEqual<T>(T?, T?)` remains | **`CS0411`** (type arguments cannot be inferred) or `CS1503` -- but only where the two arguments have no common inferred type. Two `object`-typed arguments still infer `T = object` and **compile unchanged** | Add the explicit type argument on the failing call: `Assert.AreEqual<object>(expected, actual)`. Same for `AreNotEqual`, `AreSame`, `AreNotSame`. Leave assertions that already compile alone | | `DataRow` strict type matching | **Not a compile error.** Builds with analyzer warning `MSTEST0014` and fails at run time with "Test data doesn't match method parameters". Widening conversions (`int` -> `long`) still bind; narrowing or unrelated types (`1L` -> `int`, `1.0` -> `float`) do not | Change literals to the exact parameter type: `1` for int, `1L` for long, `1.0f` for float. Run the tests -- a green build proves nothing here | | `DataRow` limited to 16 arguments -- **3.0.1 and 3.0.2 only** | `CS1729` on those two versions; the limit was removed again in **3.0.3** | On 3.0.3+ (every current 3.x) a longer row is valid -- **leave it unchanged**. Do not wrap extras in an array, cast to `object`, or split the test. Only a project pinned to 3.0.1/3.0.2 needs action: update to 3.0.3+ | | `.testsettings` / `<LegacySettings>` no longer supported | Settings silently ignored | Delete `.testsettings`, create `.runsettings` with equivalent config | | Timeout behavior unified across .NET Core / Framework | Tests with `[Timeout]` may behave differently | Verify timeout values; adjust if needed | | Dropped target frameworks: .NET 5, .NET Fx < 4.6.2, netstandard1.0, UWP < 16299, WinUI < 18362 | Build error | Update TFM: .NET 5 -> net8.0 (LTS