---

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 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) or net6.0+, netfx -> net462+, netstandard1.0 -> netstandard2.0. Note: net6.0, net8.0, net9.0 are all supported | | Not binary compatible with v1/v2 | Libraries compiled against v1/v2 must be recompiled | Recompile all dependencies against v3 | | Test ID generation changed | Playlists, filters, or CI history keyed by test ID may reset | Re-baseline IDs and verify affected filters | | TargetInvocationException is unwrapped | Tests or infrastructure expecting the wrapper observe the inner exception | Update exception handling to expect the underlying exception | | Initialization/cleanup messages now attach to test results | The first/last test output may gain lifecycle messages that were previously absent | Update log processing and inspect the first/last test results | | Deployment directory behavior is unified across TFMs | Tests with hard-coded deployment paths may fail | Use TestContext.DeploymentDirectory or deployed-item paths instead of assumptions | | Nullable annotations were added | Nullable-enabled projects may gain warnings | Fix the warnings without suppressing unrelated diagnostics |

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 v2 (2.2.10)" or "This is an MSTest v1 project using QualityTools assembly references"). This grounds the migration advice and confirms you've read the project files.
• Require project evidence, but gather it yourself: Do not assume v1/v2 from the wording alone -- read the project or central package files and classify the source as QualityTools/v1, NuGet 1.x, or NuGet 2.x. Gather that evidence from the working directory rather than asking the user for it. If the project is already on v3+ with no v1/v2 leftovers, stop and route to the appropriate skill.
• Preserve the test platform: Keep VSTest or MTP unchanged during the framework upgrade unless the user separately requests a runner migration.
• Execute full migrations: When the user asks you to migrate or upgrade the project, edit the files, build, and run tests. Do not stop after listing breaking changes. Advice-only responses are appropriate only when the user asks what to expect.
• Focused fix requests (user has specific compilation errors after upgrading): Address only the relevant breaking change from the table above. Show a concise before/after fix. Do not walk through the full migration workflow.
• DataRow fix requests: Compare every supplied DataRow with its method signature. Mismatches can build with only MSTEST0014 and fail during test execution. Preserve the method contract and normally fix the literal (1L -> 1 for int), then run the affected tests. Change only the rows that are actually wrong. Argument count is not itself a defect on 3.0.3+, so leave a long row alone unless the compiler rejects it.
• Change nothing on suspicion -- confirm the error first: When you believe a construct is unsupported, build and read the actual diagnostic before editing it. If it compiles, this version supports it and it needs no change. Rewriting valid code to dodge a limit the project is not subject to is a defect, not caution.
• Specific feature migration (user asks about one aspect like .testsettings, DataRow, or assertions): Address only that feature, but handle every active setting or affected usage in the supplied files. For .testsettings, put all MSTest settings under one <MSTest> element, map requested deployment, per-test timeout, data collector, and other active configuration, and do not add a session-wide timeout. Do not walk through unrelated breaking changes.
• "What to expect" questions (user asks about breaking changes before upgrading): First state the concrete package update needed to reach v3, then summarize every category in the Breaking Changes Summary, marking which ones directly apply to the visible project. Keep each item to one line and do not expand into release-note history.
• Required shape for "what to expect": Use an Applies / Watch / No change table grounded in the visible project and cover every row in the Breaking Changes Summary. This completeness is the value of the skill; do not omit runtime-only categories merely to be concise.
• Full migration requests (user wants complete migration): Follow the complete workflow below.
• Comparison questions (user asks about v1 vs v2 differences): Explain concisely -- v1 uses assembly references and requires removing them first; v2 uses NuGet and just needs a version bump. Both converge on the same v3 packages and breaking changes.
• **Keep execution proj