/migrate-mstest-v1v2-to-v3

name: migrate-mstest-v1v2-to-v3
description: >
  Use this skill before answering or editing whenever an MSTest v1/v2 project
  is being upgraded or repaired for v3. Triggers include QualityTools assembly
  references; MSTest.TestFramework/TestAdapter 1.x-2.x; "upgrade to MSTest
  v3"; comparing v1 and v2 migration paths; choosing MSTest or MSTest.Sdk;
  CS0411/CS1503 after a v3 package bump; DataRow type mismatch,
  MSTEST0014, or "Test data doesn't match method parameters";
  .testsettings/LegacySettings to .runsettings; timeout changes; and net5.0 or
  other dropped v3 TFMs. Still use it when packages say 3.x but migration
  source errors or legacy settings remain. Preserve VSTest/MTP. Do not use for
  a clean v3 project, v3-to-v4, framework conversion, or runner-only migration.
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.

First Action

Inspect the supplied workspace and classify v1, v2, partially migrated v3, or already-complete v3 before answering. Do not search the web or answer from memory first. For an edit request, continue through the requested source changes and validation; for an advice request, answer directly after the classification.

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.

Execution Contract

• Skill activation is not a stopping point. Continue with workspace discovery and the requested work in the same task.
• The skill directory contains guidance, not the staged project. Search the current working directory, open the literal paths returned by the search, and retry with another available reader/editor if one tool rejects a valid path.
• Never ask for a path while a glob or directory search can discover it. Ask only after an exhaustive current-workspace search finds no project, or multiple projects make the target genuinely ambiguous.
• Classify the requested deliverable, not isolated verbs: "make the edits", "update this project", or "then build and run" means execute; "what do I need to change?", "what should I expect?", "are the steps the same?", or "show me" means answer, even if the prompt also says upgrade or migrate.
• After changing files, name the detected MSTest version and runner, every file changed, and the exact repaired calls/settings (for example, list each assertion changed to `AreEqual<object>`, `AreNotEqual<object>`, or `AreSame<object>`). Report the clean test counts. Do not claim VSTest preservation, a build, or passing tests without evidence from the project.

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 alrea