[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DZKH79B36ECZ2STSZF4RC4":3,"skill-same:01M6DZKH79B36ECZ2STSZF4RC4":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6DZKH79B36ECZ2STSZF4RC4","migrate-mstest-v1v2-to-v3",null,"Use this skill before answering or editing whenever an MSTest v1\u002Fv2 project is being upgraded or repaired for v3. Triggers include QualityTools assembly references; MSTest.TestFramework\u002FTestAdapter 1.x-2.x; \"upgrade to MSTest v3\"; comparing v1 and v2 migration paths; choosing MSTest or MSTest.Sdk; CS0411\u002FCS1503 after a v3 package bump; DataRow type mismatch, MSTEST0014, or \"Test data doesn't match method parameters\"; .testsettings\u002FLegacySettings 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\u002FMTP. Do not use for a clean v3 project, v3-to-v4, framework conversion, or runner-only migration.","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",512,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-test-migration\u002Fskills\u002Fmigrate-mstest-v1v2-to-v3\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"migrate","migrate mstest v1v2 to v3","v3","mstest","clean","when","source","errors","paths","project","upgrade","but","runner","do","references","conversion","bump","assembly","only","editing","data","framework","packages","2026-11-10 10:12:30",false,"---\nname: migrate-mstest-v1v2-to-v3\ndescription: >\n  Use this skill before answering or editing whenever an MSTest v1\u002Fv2 project\n  is being upgraded or repaired for v3. Triggers include QualityTools assembly\n  references; MSTest.TestFramework\u002FTestAdapter 1.x-2.x; \"upgrade to MSTest\n  v3\"; comparing v1 and v2 migration paths; choosing MSTest or MSTest.Sdk;\n  CS0411\u002FCS1503 after a v3 package bump; DataRow type mismatch,\n  MSTEST0014, or \"Test data doesn't match method parameters\";\n  .testsettings\u002FLegacySettings to .runsettings; timeout changes; and net5.0 or\n  other dropped v3 TFMs. Still use it when packages say 3.x but migration\n  source errors or legacy settings remain. Preserve VSTest\u002FMTP. Do not use for\n  a clean v3 project, v3-to-v4, framework conversion, or runner-only migration.\nlicense: MIT\n---\n\n# MSTest v1\u002Fv2 -> v3 Migration\n\nMigrate 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\u002Fv2 -- libraries compiled against v1\u002Fv2 must be recompiled.\n\n## First Action\n\nInspect the supplied workspace and classify v1, v2, partially migrated v3, or\nalready-complete v3 before answering. Do not search the web or answer from\nmemory first. For an edit request, continue through the requested source\nchanges and validation; for an advice request, answer directly after the\nclassification.\n\n## When to Use\n\n- Project references `Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll` (MSTest v1)\n- Project uses `MSTest.TestFramework` \u002F `MSTest.TestAdapter` NuGet 1.x or 2.x\n- Resolving build errors after updating MSTest packages from v1\u002Fv2 to v3 -- including when the packages already read 3.x and only the source or settings still need fixing\n- Replacing `.testsettings` with `.runsettings`\n- Adopting MSTest.Sdk or in-assembly parallel execution\n\n## When Not to Use\n\n- Project already on MSTest v3 with no migration-related build errors and no leftover `.testsettings` \u002F `\u003CLegacySettings>` (fully migrated)\n- Upgrading v3 to v4 -- use `migrate-mstest-v3-to-v4`\n- Migrating between frameworks (MSTest to xUnit\u002FNUnit)\n\n## Boundary Gate\n\nCheck package versions before any edit. If all MSTest references are already 3.x,\nno v1\u002Fv2-to-v3 error is reported, and no `.testsettings` or `\u003CLegacySettings>`\nremains, state that migration is complete and make no changes. A 3.x package\nversion alone does not end the migration -- leftover v1\u002Fv2-era settings files or\nbreaking-change errors are still in scope. Do not consolidate working v3 packages\ninto the metapackage. Run the existing tests only if verification was requested.\nThis overrides all steps below.\n\n## Inputs\n\n| Input | Required | Description |\n|-------|----------|-------------|\n| 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 |\n| Build command | No | How to build (e.g., `dotnet build`, a repo build script). Auto-detect if not provided |\n| Test command | No | How to run tests (e.g., `dotnet test`). Auto-detect if not provided |\n\n> **Never open by asking for the project path.** A user describing their project\n> in prose is asking a question, not withholding a file -- look on disk first. If\n> there is genuinely no project file, answer for the setup they described rather\n> than replying with only a question.\n>\n> **Open the paths exactly as the search returned them.** A glob that answers\n> `.\u002FTestProject.csproj` means the file is there, relative to the working\n> directory -- read it at that path. Do not rebuild it into an absolute path\n> under this skill's own base directory: that directory holds `SKILL.md`, not the\n> user's project, so the read fails and the project looks missing when it is not.\n> If a file you just found fails to open, the path you constructed is wrong --\n> retry with the literal result. Never conclude \"there is no project on disk\"\n> while a search is still reporting project files, and never scaffold a\n> substitute project from the prose description as a workaround.\n\n## Execution Contract\n\n- Skill activation is not a stopping point. Continue with workspace discovery and the requested work in the same task.\n- 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\u002Feditor if one tool rejects a valid path.\n- 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.\n- 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.\n- After changing files, name the detected MSTest version and runner, every file changed, and the exact repaired calls\u002Fsettings (for example, list each assertion changed to `AreEqual\u003Cobject>`, `AreNotEqual\u003Cobject>`, or `AreSame\u003Cobject>`). Report the clean test counts. Do not claim VSTest preservation, a build, or passing tests without evidence from the project.\n\n## Breaking Changes Summary\n\nMSTest v3 introduces these breaking changes from v1\u002Fv2. Address only the ones relevant to the project:\n\n| Breaking Change | Impact | Fix |\n|---|---|---|\n| `Assert.AreEqual(object, object)` overload removed; only `AreEqual\u003CT>(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\u003Cobject>(expected, actual)`. Same for `AreNotEqual`, `AreSame`, `AreNotSame`. Leave assertions that already compile alone |\n| `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 |\n| `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\u002F3.0.2 needs action: update to 3.0.3+ |\n| `.testsettings` \u002F `\u003CLegacySettings>` no longer supported | Settings silently ignored | Delete `.testsettings`, create `.runsettings` with equivalent config |\n| Timeout behavior unified across .NET Core \u002F Framework | Tests with `[Timeout]` may behave differently | Verify timeout values; adjust if needed |\n| Dropped target frameworks: .NET 5, .NET Fx \u003C 4.6.2, netstandard1.0, UWP \u003C 16299, WinUI \u003C 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 |\n| Not binary compatible with v1\u002Fv2 | Libraries compiled against v1\u002Fv2 must be recompiled | Recompile all dependencies against v3 |\n| Test ID generation changed | Playlists, filters, or CI history keyed by test ID may reset | Re-baseline IDs and verify affected filters |\n| `TargetInvocationException` is unwrapped | Tests or infrastructure expecting the wrapper observe the inner exception | Update exception handling to expect the underlying exception |\n| Initialization\u002Fcleanup messages now attach to test results | The first\u002Flast test output may gain lifecycle messages that were previously absent | Update log processing and inspect the first\u002Flast test results |\n| 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 |\n| Nullable annotations were added | Nullable-enabled projects may gain warnings | Fix the warnings without suppressing unrelated diagnostics |\n\n## Response Guidelines\n\n- **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.\n- **Require project evidence, but gather it yourself**: Do not assume v1\u002Fv2 from the wording alone -- read the project or central package files and classify the source as QualityTools\u002Fv1, 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\u002Fv2 leftovers, stop and route to the appropriate skill.\n- **Preserve the test platform**: Keep VSTest or MTP unchanged during the framework upgrade unless the user separately requests a runner migration.\n- **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.\n- **Focused fix requests** (user has specific compilation errors after upgrading): Address only the relevant breaking change from the table above. Show a concise before\u002Fafter fix. Do not walk through the full migration workflow.\n- **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.\n- **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.\n- **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 `\u003CMSTest>` 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.\n- **\"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.\n- **Required shape for \"what to expect\"**: Use an `Applies \u002F Watch \u002F 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.\n- **Full migration requests** (user wants complete migration): Follow the complete workflow below.\n- **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.\n- **Keep execution project-specific**: For fixes and full migrations, change only patterns found in the visible code\u002Fconfiguration. Broader coverage is reserved for explicit \"what should I expect?\" questions.\n\n## Migration Paths\n\n- **MSTest v1 (assembly reference to QualityTools)**: Remove the assembly reference (Step 2), add v3 NuGet packages (Step 3), fix breaking changes (Step 5).\n- **MSTest v2 (NuGet packages 1.x-2.x)**: Update package versions to 3.x (Step 3), fix breaking changes (Step 5). No assembly reference removal needed.\n\nBoth paths converge at Step 3 -- the same v3 packages and breaking changes apply regardless of starting version.\n\n## Workflow\n\n### Step 1: Assess the project\n\n1. Locate the project first: glob the working directory for `*.csproj`, `*.sln`,\n   `*.slnx`, `Directory.Build.props`, `Directory.Packages.props`, and\n   `*.testsettings`. Do this before asking the user anything, and open whatever\n   it returns at exactly the path it reported (see the note under Inputs).\n2. In one discovery pass, batch-read project and central configuration files, search for affected APIs\u002Fsettings, and identify which MSTest version is currently in use:\n   - **Assembly reference**: Look for `Microsoft.VisualStudio.QualityTools.UnitTestFramework` in project references -> MSTest v1\n   - **NuGet packages**: Check `MSTest.TestFramework` and `MSTest.TestAdapter` package versions -> v1 if 1.x, v2 if 2.x\n3. Check whether the target framework is dropped in v3 (see Step 4).\n4. Run the existing test command. Record discovered, passed, failed, and skipped counts as the parity baseline.\n\n### Step 2: Remove v1 assembly references (if applicable)\n\nIf the project uses MSTest v1 via assembly references:\n\n1. Remove the reference to `Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll`\n   - In SDK-style projects, remove the `\u003CReference>` element from the `.csproj`\n   - In non-SDK-style projects, remove via Visual Studio Solution Explorer -> References -> right-click -> Remove\n2. Save the project file\n\n### Step 3: Update packages to MSTest v3\n\nUse one package model; do not leave duplicate framework\u002Fadapter references.\n\n**Default -- install the MSTest metapackage:**\n\nRemove individual `MSTest.TestFramework` and `MSTest.TestAdapter` package references and replace with the unified `MSTest` metapackage:\n\n```xml\n\u003CPackageReference Include=\"MSTest\" Version=\"3.8.0\" \u002F>\n```\n\nKeep `Microsoft.NET.Test.Sdk` when the project remains on VSTest, but update it to a version compatible with the selected MSTest release. For example, `MSTest` 3.8.0 requires `Microsoft.NET.Test.Sdk` 17.13.0 or later; leaving an older explicit version causes `NU1605`. If package versions are centrally managed, update `Directory.Packages.props` rather than adding inline versions.\n\n**Use MSTest.Sdk only when the user requests it or the repository already standardizes on it (SDK-style projects only):**\n\nChange `\u003CProject Sdk=\"Microsoft.NET.Sdk\">` to `\u003CProject Sdk=\"MSTest.Sdk\u002F3.8.0\">`. MSTest.Sdk automatically provides the MSTest framework, adapter, and analyzers.\n\n> **Important**: MSTest.Sdk defaults to Microsoft.Testing.Platform (MTP). When the\n> project itself must remain on VSTest, set `\u003CUseVSTest>true\u003C\u002FUseVSTest>`. MSTest.Sdk\n> v3 also supplies `Microsoft.NET.Test.Sdk` in MTP mode, so a separate transitional\n> `vstest.console` invocation does not by itself require changing the primary runner.\n> Do not switch runners merely as a side effect of the framework upgrade.\n\nWhen switching to MSTest.Sdk, remove these (SDK provides them automatically):\n\n- **Packages**: `MSTest`, `MSTest.TestFramework`, `MSTest.TestAdapter`, `MSTest.Analyzers`, `Microsoft.NET.Test.Sdk`\n- **Properties**: `\u003CEnableMSTestRunner>`, `\u003COutputType>Exe\u003C\u002FOutputType>`, `\u003CIsPackable>false\u003C\u002FIsPackable>`, `\u003CIsTestProject>true\u003C\u002FIsTestProject>`\n\n### Step 4: Update target frameworks if needed\n\nMSTest v3 supports .NET 6+, .NET Core 3.1, .NET Framework 4.6.2+, .NET Standard 2.0, UWP 16299+, and WinUI 18362+. .NET Core 3.1 is end-of-life but remains supported by MSTest v3; preserve it during this framework-only migration and recommend a separate runtime upgrade. If the project targets a framework version dropped by MSTest v3, update to a supported one:\n\n| Dropped | Recommended replacement |\n|---------|------------------------|\n| .NET 5 | .NET 8.0 (current LTS) or .NET 6+ |\n| .NET Framework \u003C 4.6.2 | .NET Framework 4.6.2 |\n| .NET Standard 1.0 | .NET Standard 2.0 |\n| UWP \u003C 16299 | UWP 16299 |\n| WinUI \u003C 18362 | WinUI 18362 |\n\n> **Note**: .NET 6, .NET 8, and .NET 9 are all supported by MSTest v3. Do not change TFMs that are already supported.\n\n### Step 5: Resolve build errors and breaking changes\n\nSearch the supplied files first and fix only breaking changes that are present.\nA successful build does not prove compatibility; some failures surface only as\nanalyzer warnings or during test execution.\n\n**Assertion overloads** -- MSTest v3 replaced `Assert.AreEqual(object, object)` and `AreNotEqual(object, object)` with the generic `AreEqual\u003CT>(T?, T?)`. This breaks **only** where `T` can no longer be inferred, which the compiler reports as `CS0411` (or `CS1503` for unrelated argument types):\n\n```csharp\n\u002F\u002F Breaks -- string and int have no common inferred type:\nAssert.AreEqual(referenceCode, numericId);   \u002F\u002F CS0411\n\u002F\u002F Fix -- name the type argument explicitly:\nAssert.AreEqual\u003Cobject>(referenceCode, numericId);\n```\n\nTwo `object`-typed arguments still infer `T = object` and compile untouched, as do\nordinary typed assertions like `Assert.AreEqual(\"A-3\", order.Reference)`. **Fix only\nthe call sites the compiler rejects.** Widening every assertion in the file to\n`\u003Cobject>` also compiles, so nothing will flag it -- but it discards the type\nchecking v3 added, which is the entire point of the change.\n\n**DataRow strict type matching** -- argument types must match parameter types\nexactly. This is **not** a compile error: the row builds (with `MSTEST0014`) and\nfails at run time with \"Test data doesn't match method parameters\".\n\n```csharp\n\u002F\u002F Fails at run time: 1L (long) does not bind to an int parameter -> use 1\n\u002F\u002F Fails at run time: 1.0 (double) does not bind to a float parameter -> use 1.0f\n\u002F\u002F Still binds: 1 (int) to a long parameter -- widening conversions are accepted\n```\n\nPreserve method parameter types unless independently wrong. `dotnet build` may\nsucceed with `MSTEST0014`; run the test to prove each row binds and executes.\n\n**Rows with more than 16 arguments** -- leave them alone unless the compiler\nactually emits `CS1729`. The cap existed only in 3.0.1\u002F3.0.2 (removed in 3.0.3),\nso wrapping extras in an `object[]`, casting to `object`, or splitting the method\njust rewrites a correct test.\n\n**Timeout behavior** -- unified across .NET Core and .NET Framework. Verify `[Timeout]` values still work.\n\n### Step 6: Replace .testsettings with .runsettings\n\nThe `.testsettings` file and `\u003CLegacySettings>` are no longer supported in MSTest v3. **Delete the `.testsettings` file** and create a `.runsettings` file -- do not keep both. Consolidate all MSTest configuration under one `\u003CMSTest>` element; do not create an `\u003CMSTestV2>` section.\n\nKey mappings:\n\n| .testsettings | .runsettings equivalent |\n|---|---|\n| `TestTimeout` property | `\u003CMSTest>\u003CTestTimeout>30000\u003C\u002FTestTimeout>\u003C\u002FMSTest>` |\n| Deployment config | `\u003CMSTest>\u003CDeploymentEnabled>true\u003C\u002FDeploymentEnabled>\u003C\u002FMSTest>` or remove |\n| Assembly resolution settings | Remove -- not needed in modern .NET |\n| Data collectors | `\u003CDataCollectionRunSettings>\u003CDataCollectors>` section |\n\n> **Important**: Map timeout to `\u003CMSTest>\u003CTestTimeout>` (per-test), **not** `\u003CTestSessionTimeout>` (session-wide). Remove `\u003CLegacySettings>` entirely.\n\nUpdate every project, CI command, or IDE setting that explicitly selected the old\n`.testsettings` path to select the new `.runsettings` path. When a VSTest project\nmust preserve behavior but the legacy file was never selected, make the new file\neffective with `RunSettingsFilePath`. For MTP, use the framework-supported\n`--settings` path or existing MTP configuration instead of assuming the VSTest\nMSBuild property is honored.\n\n### Step 7: Verify\n\n1. Run the same test command, filter, and configuration used for the baseline. `dotnet test` builds by default; run a separate build only to isolate a compilation failure.\n2. Compare discovered, passed, failed, and skipped counts to the pre-migration baseline.\n3. Investigate every count difference; do not accept silently dropped tests or data rows.\n4. Confirm no QualityTools reference, 1.x\u002F2.x MSTest package, `.testsettings`, or `\u003CLegacySettings>` remains.\n\n## Validation\n\n- [ ] MSTest v3 packages (or MSTest.Sdk) correctly referenced; v1\u002Fv2 references removed\n- [ ] Project builds with zero errors\n- [ ] All tests pass (`dotnet test`) -- compare pass\u002Ffail counts to pre-migration baseline\n- [ ] `.testsettings` replaced with `.runsettings` (if applicable)\n\n## Next Step\n\nAfter v3 migration, use `migrate-mstest-v3-to-v4` for MSTest v4.\n\n## Common Pitfalls\n\n| Pitfall | Solution |\n|---------|----------|\n| Replying with \"which project?\" when the workspace already holds one | Glob for `*.csproj`\u002F`*.sln`\u002F`*.slnx` and read what is there |\n| \"No project on disk\" right after a search listed project files | The path was rebuilt under the skill's base directory. Reopen using the literal search result; never scaffold a replacement project |\n| Rewriting a `DataRow` with more than 16 arguments | Valid on 3.0.3+, which is every current 3.x. Only 3.0.1\u002F3.0.2 ever rejected it |\n| Non-MSTest.Sdk VSTest project missing `Microsoft.NET.Test.Sdk` | Add the package reference for VSTest discovery |\n| MSTest.Sdk v3 project must use VSTest as its primary runner | Set `\u003CUseVSTest>true\u003C\u002FUseVSTest>`; do not flip the runner merely because a transitional `vstest.console` job also exists |\n","# MSTest v1\u002Fv2 -> v3 Migration\n\nMigrate 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\u002Fv2 -- libraries compiled against v1\u002Fv2 must be recompiled.\n\n## First Action\n\nInspect the supplied workspace and classify v1, v2, partially migrated v3, or\nalready-complete v3 before answering. Do not search the web or answer from\nmemory first. For an edit request, continue through the requested source\nchanges and validation; for an advice request, answer directly after the\nclassification.\n\n## When to Use\n\n- Project references `Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll` (MSTest v1)\n- Project uses `MSTest.TestFramework` \u002F `MSTest.TestAdapter` NuGet 1.x or 2.x\n- Resolving build errors after updating MSTest packages from v1\u002Fv2 to v3 -- including when the packages already read 3.x and only the source or settings still need fixing\n- Replacing `.testsettings` with `.runsettings`\n- Adopting MSTest.Sdk or in-assembly parallel execution\n\n## When Not to Use\n\n- Project already on MSTest v3 with no migration-related build errors and no leftover `.testsettings` \u002F `\u003CLegacySettings>` (fully migrated)\n- Upgrading v3 to v4 -- use `migrate-mstest-v3-to-v4`\n- Migrating between frameworks (MSTest to xUnit\u002FNUnit)\n\n## Boundary Gate\n\nCheck package versions before any edit. If all MSTest references are already 3.x,\nno v1\u002Fv2-to-v3 error is reported, and no `.testsettings` or `\u003CLegacySettings>`\nremains, state that migration is complete and make no changes. A 3.x package\nversion alone does not end the migration -- leftover v1\u002Fv2-era settings files or\nbreaking-change errors are still in scope. Do not consolidate working v3 packages\ninto the metapackage. Run the existing tests only if verification was requested.\nThis overrides all steps below.\n\n## Inputs\n\n| Input | Required | Description |\n|-------|----------|-------------|\n| 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 |\n| Build command | No | How to build (e.g., `dotnet build`, a repo build script). Auto-detect if not provided |\n| Test command | No | How to run tests (e.g., `dotnet test`). Auto-detect if not provided |\n\n> **Never open by asking for the project path.** A user describing their project\n> in prose is asking a question, not withholding a file -- look on disk first. If\n> there is genuinely no project file, answer for the setup they described rather\n> than replying with only a question.\n>\n> **Open the paths exactly as the search returned them.** A glob that answers\n> `.\u002FTestProject.csproj` means the file is there, relative to the working\n> directory -- read it at that path. Do not rebuild it into an absolute path\n> under this skill's own base directory: that directory holds `SKILL.md`, not the\n> user's project, so the read fails and the project looks missing when it is not.\n> If a file you just found fails to open, the path you constructed is wrong --\n> retry with the literal result. Never conclude \"there is no project on disk\"\n> while a search is still reporting project files, and never scaffold a\n> substitute project from the prose description as a workaround.\n\n## Execution Contract\n\n- Skill activation is not a stopping point. Continue with workspace discovery and the requested work in the same task.\n- 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\u002Feditor if one tool rejects a valid path.\n- 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.\n- 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.\n- After changing files, name the detected MSTest version and runner, every file changed, and the exact repaired calls\u002Fsettings (for example, list each assertion changed to `AreEqual\u003Cobject>`, `AreNotEqual\u003Cobject>`, or `AreSame\u003Cobject>`). Report the clean test counts. Do not claim VSTest preservation, a build, or passing tests without evidence from the project.\n\n## Breaking Changes Summary\n\nMSTest v3 introduces these breaking changes from v1\u002Fv2. Address only the ones relevant to the project:\n\n| Breaking Change | Impact | Fix |\n|---|---|---|\n| `Assert.AreEqual(object, object)` overload removed; only `AreEqual\u003CT>(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\u003Cobject>(expected, actual)`. Same for `AreNotEqual`, `AreSame`, `AreNotSame`. Leave assertions that already compile alone |\n| `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 |\n| `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\u002F3.0.2 needs action: update to 3.0.3+ |\n| `.testsettings` \u002F `\u003CLegacySettings>` no longer supported | Settings silently ignored | Delete `.testsettings`, create `.runsettings` with equivalent config |\n| Timeout behavior unified across .NET Core \u002F Framework | Tests with `[Timeout]` may behave differently | Verify timeout values; adjust if needed |\n| Dropped target frameworks: .NET 5, .NET Fx \u003C 4.6.2, netstandard1.0, UWP \u003C 16299, WinUI \u003C 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 |\n| Not binary compatible with v1\u002Fv2 | Libraries compiled against v1\u002Fv2 must be recompiled | Recompile all dependencies against v3 |\n| Test ID generation changed | Playlists, filters, or CI history keyed by test ID may reset | Re-baseline IDs and verify affected filters |\n| `TargetInvocationException` is unwrapped | Tests or infrastructure expecting the wrapper observe the inner exception | Update exception handling to expect the underlying exception |\n| Initialization\u002Fcleanup messages now attach to test results | The first\u002Flast test output may gain lifecycle messages that were previously absent | Update log processing and inspect the first\u002Flast test results |\n| 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 |\n| Nullable annotations were added | Nullable-enabled projects may gain warnings | Fix the warnings without suppressing unrelated diagnostics |\n\n## Response Guidelines\n\n- **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.\n- **Require project evidence, but gather it yourself**: Do not assume v1\u002Fv2 from the wording alone -- read the project or central package files and classify the source as QualityTools\u002Fv1, 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\u002Fv2 leftovers, stop and route to the appropriate skill.\n- **Preserve the test platform**: Keep VSTest or MTP unchanged during the framework upgrade unless the user separately requests a runner migration.\n- **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.\n- **Focused fix requests** (user has specific compilation errors after upgrading): Address only the relevant breaking change from the table above. Show a concise before\u002Fafter fix. Do not walk through the full migration workflow.\n- **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.\n- **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.\n- **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 `\u003CMSTest>` 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.\n- **\"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.\n- **Required shape for \"what to expect\"**: Use an `Applies \u002F Watch \u002F 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.\n- **Full migration requests** (user wants complete migration): Follow the complete workflow below.\n- **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.\n- **Keep execution project-specific**: For fixes and full migrations, change only patterns found in the visible code\u002Fconfiguration. Broader coverage is reserved for explicit \"what should I expect?\" questions.\n\n## Migration Paths\n\n- **MSTest v1 (assembly reference to QualityTools)**: Remove the assembly reference (Step 2), add v3 NuGet packages (Step 3), fix breaking changes (Step 5).\n- **MSTest v2 (NuGet packages 1.x-2.x)**: Update package versions to 3.x (Step 3), fix breaking changes (Step 5). No assembly reference removal needed.\n\nBoth paths converge at Step 3 -- the same v3 packages and breaking changes apply regardless of starting version.\n\n## Workflow\n\n### Step 1: Assess the project\n\n1. Locate the project first: glob the working directory for `*.csproj`, `*.sln`,\n   `*.slnx`, `Directory.Build.props`, `Directory.Packages.props`, and\n   `*.testsettings`. Do this before asking the user anything, and open whatever\n   it returns at exactly the path it reported (see the note under Inputs).\n2. In one discovery pass, batch-read project and central configuration files, search for affected APIs\u002Fsettings, and identify which MSTest version is currently in use:\n   - **Assembly reference**: Look for `Microsoft.VisualStudio.QualityTools.UnitTestFramework` in project references -> MSTest v1\n   - **NuGet packages**: Check `MSTest.TestFramework` and `MSTest.TestAdapter` package versions -> v1 if 1.x, v2 if 2.x\n3. Check whether the target framework is dropped in v3 (see Step 4).\n4. Run the existing test command. Record discovered, passed, failed, and skipped counts as the parity baseline.\n\n### Step 2: Remove v1 assembly references (if applicable)\n\nIf the project uses MSTest v1 via assembly references:\n\n1. Remove the reference to `Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll`\n   - In SDK-style projects, remove the `\u003CReference>` element from the `.csproj`\n   - In non-SDK-style projects, remove via Visual Studio Solution Explorer -> References -> right-click -> Remove\n2. Save the project file\n\n### Step 3: Update packages to MSTest v3\n\nUse one package model; do not leave duplicate framework\u002Fadapter references.\n\n**Default -- install the MSTest metapackage:**\n\nRemove individual `MSTest.TestFramework` and `MSTest.TestAdapter` package references and replace with the unified `MSTest` metapackage:\n\n```xml\n\u003CPackageReference Include=\"MSTest\" Version=\"3.8.0\" \u002F>\n```\n\nKeep `Microsoft.NET.Test.Sdk` when the project remains on VSTest, but update it to a version compatible with the selected MSTest release. For example, `MSTest` 3.8.0 requires `Microsoft.NET.Test.Sdk` 17.13.0 or later; leaving an older explicit version causes `NU1605`. If package versions are centrally managed, update `Directory.Packages.props` rather than adding inline versions.\n\n**Use MSTest.Sdk only when the user requests it or the repository already standardizes on it (SDK-style projects only):**\n\nChange `\u003CProject Sdk=\"Microsoft.NET.Sdk\">` to `\u003CProject Sdk=\"MSTest.Sdk\u002F3.8.0\">`. MSTest.Sdk automatically provides the MSTest framework, adapter, and analyzers.\n\n> **Important**: MSTest.Sdk defaults to Microsoft.Testing.Platform (MTP). When the\n> project itself must remain on VSTest, set `\u003CUseVSTest>true\u003C\u002FUseVSTest>`. MSTest.Sdk\n> v3 also supplies `Microsoft.NET.Test.Sdk` in MTP mode, so a separate transitional\n> `vstest.console` invocation does not by itself require changing the primary runner.\n> Do not switch runners merely as a side effect of the framework upgrade.\n\nWhen switching to MSTest.Sdk, remove these (SDK provides them automatically):\n\n- **Packages**: `MSTest`, `MSTest.TestFramework`, `MSTest.TestAdapter`, `MSTest.Analyzers`, `Microsoft.NET.Test.Sdk`\n- **Properties**: `\u003CEnableMSTestRunner>`, `\u003COutputType>Exe\u003C\u002FOutputType>`, `\u003CIsPackable>false\u003C\u002FIsPackable>`, `\u003CIsTestProject>true\u003C\u002FIsTestProject>`\n\n### Step 4: Update target frameworks if needed\n\nMSTest v3 supports .NET 6+, .NET Core 3.1, .NET Framework 4.6.2+, .NET Standard 2.0, UWP 16299+, and WinUI 18362+. .NET Core 3.1 is end-of-life but remains supported by MSTest v3; preserve it during this framework-only migration and recommend a separate runtime upgrade. If the project targets a framework version dropped by MSTest v3, update to a supported one:\n\n| Dropped | Recommended replacement |\n|---------|------------------------|\n| .NET 5 | .NET 8.0 (current LTS) or .NET 6+ |\n| .NET Framework \u003C 4.6.2 | .NET Framework 4.6.2 |\n| .NET Standard 1.0 | .NET Standard 2.0 |\n| UWP \u003C 16299 | UWP 16299 |\n| WinUI \u003C 18362 | WinUI 18362 |\n\n> **Note**: .NET 6, .NET 8, and .NET 9 are all supported by MSTest v3. Do not change TFMs that are already supported.\n\n### Step 5: Resolve build errors and breaking changes\n\nSearch the supplied files first and fix only breaking changes that are present.\nA successful build does not prove compatibility; some failures surface only as\nanalyzer warnings or during test execution.\n\n**Assertion overloads** -- MSTest v3 replaced `Assert.AreEqual(object, object)` and `AreNotEqual(object, object)` with the generic `AreEqual\u003CT>(T?, T?)`. This breaks **only** where `T` can no longer be inferred, which the compiler reports as `CS0411` (or `CS1503` for unrelated argument types):\n\n```csharp\n\u002F\u002F Breaks -- string and int have no common inferred type:\nAssert.AreEqual(referenceCode, numericId);   \u002F\u002F CS0411\n\u002F\u002F Fix -- name the type argument explicitly:\nAssert.AreEqual\u003Cobject>(referenceCode, numericId);\n```\n\nTwo `object`-typed arguments still infer `T = object` and compile untouched, as do\nordinary typed assertions like `Assert.AreEqual(\"A-3\", order.Reference)`. **Fix only\nthe call sites the compiler rejects.** Widening every assertion in the file to\n`\u003Cobject>` also compiles, so nothing will flag it -- but it discards the type\nchecking v3 added, which is the entire point of the change.\n\n**DataRow strict type matching** -- argument types must match parameter types\nexactly. This is **not** a compile error: the row builds (with `MSTEST0014`) and\nfails at run time with \"Test data doesn't match method parameters\".\n\n```csharp\n\u002F\u002F Fails at run time: 1L (long) does not bind to an int parameter -> use 1\n\u002F\u002F Fails at run time: 1.0 (double) does not bind to a float parameter -> use 1.0f\n\u002F\u002F Still binds: 1 (int) to a long parameter -- widening conversions are accepted\n```\n\nPreserve method parameter types unless independently wrong. `dotnet build` may\nsucceed with `MSTEST0014`; run the test to prove each row binds and executes.\n\n**Rows with more than 16 arguments** -- leave them alone unless the compiler\nactually emits `CS1729`. The cap existed only in 3.0.1\u002F3.0.2 (removed in 3.0.3),\nso wrapping extras in an `object[]`, casting to `object`, or splitting the method\njust rewrites a correct test.\n\n**Timeout behavior** -- unified across .NET Core and .NET Framework. Verify `[Timeout]` values still work.\n\n### Step 6: Replace .testsettings with .runsettings\n\nThe `.testsettings` file and `\u003CLegacySettings>` are no longer supported in MSTest v3. **Delete the `.testsettings` file** and create a `.runsettings` file -- do not keep both. Consolidate all MSTest configuration under one `\u003CMSTest>` element; do not create an `\u003CMSTestV2>` section.\n\nKey mappings:\n\n| .testsettings | .runsettings equivalent |\n|---|---|\n| `TestTimeout` property | `\u003CMSTest>\u003CTestTimeout>30000\u003C\u002FTestTimeout>\u003C\u002FMSTest>` |\n| Deployment config | `\u003CMSTest>\u003CDeploymentEnabled>true\u003C\u002FDeploymentEnabled>\u003C\u002FMSTest>` or remove |\n| Assembly resolution settings | Remove -- not needed in modern .NET |\n| Data collectors | `\u003CDataCollectionRunSettings>\u003CDataCollectors>` section |\n\n> **Important**: Map timeout to `\u003CMSTest>\u003CTestTimeout>` (per-test), **not** `\u003CTestSessionTimeout>` (session-wide). Remove `\u003CLegacySettings>` entirely.\n\nUpdate every project, CI command, or IDE setting that explicitly selected the old\n`.testsettings` path to select the new `.runsettings` path. When a VSTest project\nmust preserve behavior but the legacy file was never selected, make the new file\neffective with `RunSettingsFilePath`. For MTP, use the framework-supported\n`--settings` path or existing MTP configuration instead of assuming the VSTest\nMSBuild property is honored.\n\n### Step 7: Verify\n\n1. Run the same test command, filter, and configuration used for the baseline. `dotnet test` builds by default; run a separate build only to isolate a compilation failure.\n2. Compare discovered, passed, failed, and skipped counts to the pre-migration baseline.\n3. Investigate every count difference; do not accept silently dropped tests or data rows.\n4. Confirm no QualityTools reference, 1.x\u002F2.x MSTest package, `.testsettings`, or `\u003CLegacySettings>` remains.\n\n## Validation\n\n- [ ] MSTest v3 packages (or MSTest.Sdk) correctly referenced; v1\u002Fv2 references removed\n- [ ] Project builds with zero errors\n- [ ] All tests pass (`dotnet test`) -- compare pass\u002Ffail counts to pre-migration baseline\n- [ ] `.testsettings` replaced with `.runsettings` (if applicable)\n\n## Next Step\n\nAfter v3 migration, use `migrate-mstest-v3-to-v4` for MSTest v4.\n\n## Common Pitfalls\n\n| Pitfall | Solution |\n|---------|----------|\n| Replying with \"which project?\" when the workspace already holds one | Glob for `*.csproj`\u002F`*.sln`\u002F`*.slnx` and read what is there |\n| \"No project on disk\" right after a search listed project files | The path was rebuilt under the skill's base directory. Reopen using the literal search result; never scaffold a replacement project |\n| Rewriting a `DataRow` with more than 16 arguments | Valid on 3.0.3+, which is every current 3.x. Only 3.0.1\u002F3.0.2 ever rejected it |\n| Non-MSTest.Sdk VSTest project missing `Microsoft.NET.Test.Sdk` | Add the package reference for VSTest discovery |\n| MSTest.Sdk v3 project must use VSTest as its primary runner | Set `\u003CUseVSTest>true\u003C\u002FUseVSTest>`; do not flip the runner merely because a transitional `vstest.console` job also exists |\n",{"name":5,"license":15,"description":47},"Use this skill before answering or editing whenever an MSTest v1\u002Fv2 project is being upgraded or repaired for v3. Triggers include QualityTools assembly references; MSTest.TestFramework\u002FTestAdapter 1.x-2.x; \"upgrade to MSTest v3\"; comparing v1 and v2 migration paths; choosing MSTest or MSTest.Sdk; CS0411\u002FCS1503 after a v3 package bump; DataRow type mismatch, MSTEST0014, or \"Test data doesn't match method parameters\"; .testsettings\u002FLegacySettings 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\u002FMTP. Do not use for a clean v3 project, v3-to-v4, framework conversion, or runner-only migration.\n","main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","external-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-test-migration\u002Fskills\u002Fmigrate-mstest-v1v2-to-v3",41,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills","https:\u002F\u002Fskills.managed-code.com","https:\u002F\u002Fgithub.com\u002Fmanagedcode","https:\u002F\u002Fwww.managed-code.com","Open Source Community for .NET Developers: Reliable, Actively Maintained, and Community-Driven. Made in Ukraine 🇺🇦 with ❤️","2026-11-11 19:34:28",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add managedcode\u002Fdotnet-skills --skill migrate-mstest-v1v2-to-v3",{"tool":64,"command":65},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill migrate-mstest-v1v2-to-v3",{"tool":67,"command":68},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill migrate-mstest-v1v2-to-v3","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-test-migration\u002Fskills\u002Fmigrate-mstest-v1v2-to-v3\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"scripts\u002Fgrill_me.js","SCRIPT","脚本",3648,"https:\u002F\u002Fgithub.com\u002Ftkogut\u002Fagents-os-core\u002Fblob\u002Fmaster\u002Fglobal_skills\u002Fgrill-me\u002Fscripts\u002Fgrill_me.js",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"scripts\u002Fgrill_me.py",3198,"https:\u002F\u002Fgithub.com\u002Ftkogut\u002Fagents-os-core\u002Fblob\u002Fmaster\u002Fglobal_skills\u002Fgrill-me\u002Fscripts\u002Fgrill_me.py",[83,120,142,173,183,209],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":99,"publishedAt":42},"01M6DYQE1Y9FHAQHEDTVFQ3447","xtwitter-scraper","Use XTwitterScraper when a .NET application needs typed access to Xquik's X automation REST API for tweet search, user lookup, posting workflows, extraction jobs, monitors, webhooks, or giveaway draws. USE FOR: integrating the XTwitterScraper NuGet package; reviewing Xquik API client usage; modeling API-key configuration, pagination, binary exports, raw responses, retries, and webhook\u002Fevent flows in .NET. DO NOT USE FOR: unrelated stacks; direct browser automation; generic social-media strategy; or code that does not call Xquik. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FXTwitterScraper\u002Fskills\u002Fxtwitter-scraper\u002FSKILL.md",[89,94],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119],"xtwitter scraper","browser automation","workflows","run","code","browser","search","repository","api","Media","api client","access","edit","unrelated","webhooks","files","social","commands","modeling","webhook",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":132,"publishedAt":42},"01M6DYQ9S4PE1H6G8MCH9T21HR","sep","Use Sep for high-performance separated-value parsing and writing in .NET, including delimiter inference, explicit parser\u002Fwriter options, and low-allocation row\u002Fcolumn workflows. USE FOR: delimited data needs are performance-sensitive and allocation-aware; project needs explicit control over separator inference, escaping, trimming, and header behavior;. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FSep\u002Fskills\u002Fsep\u002FSKILL.md",[126,129],{"categoryNo":127,"categoryName":128,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":130,"categoryName":131,"taxonomyType":97,"taxonomyTypeDesc":98},"01JBSEEDCAT000000000000036","内容创作者",[122,133,134,102,135,103,107,39,136,137,112,138,113,115,32,139,140,28,117,141],"writing","performance","tasks","parsing","parser","context","writer","options","high-performance",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":42},"01M6DZS2DNEPXCGGF6SSCW6G5V","webgpu-threejs-tsl","Comprehensive guide for developing WebGPU-enabled Three.js applications using TSL (Three.js Shading Language). Covers WebGPU renderer setup, TSL syntax and node materials, compute shaders, post-processing effects, and WGSL integration. Use this skill when working with Three.js WebGPU, TSL shaders, node materials, or GPU compute in Three.js.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fwebgpu-claude-skill\u002Fskills\u002Fwebgpu-threejs-tsl\u002FSKILL.md",[],[149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,24],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","node","syntax","guide","use","language","three","compute","post","processing","with","renderer","for","materials","wgsl","effects",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":42},"01M6DZS0BQXW2B56A289XF1X76","roslynk","Use Roslynk for semantic inspection and edits of *.cs, *.razor and *.cshtml solution files.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Froslynk\u002Fskills\u002Froslynk\u002FSKILL.md",[],[175,161,115,180,181,169,182],"semantic","razor","inspection",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":42},"01M6DZRW6MEJCVW80K3S4XV60K","system-text-json-net11","Imperative guidance for the System.Text.Json APIs added in .NET 11: the built-in `JsonNamingPolicy.PascalCase` naming policy, and the strongly-typed generic `JsonSerializerOptions.GetTypeInfo` and `JsonSerializerOptions.TryGetTypeInfo` metadata accessors (generic overloads that return a typed `JsonTypeInfo`). USE ONLY when the user is targeting net11.0 or later and needs PascalCase JSON property or dictionary-key names without writing a custom naming policy, a strongly-typed generic `JsonTypeInfo` instead of the non-generic `JsonTypeInfo`, or a no-throw way to probe whether a type's serialization metadata is resolved. DO NOT USE when the target is earlier than net11.0, the requested behavior uses an established pre-net11 naming policy, or the user explicitly selected another JSON library.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fsystem-text-json-net11\u002FSKILL.md",[],[190,191,192,193,133,194,195,196,197,198,199,161,37,200,201,202,32,203,204,205,206,169,207,208,24],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":217,"publishedAt":42},"01M6DZRRJP3S662NFSG1RSPQQ7","process-api-net11","Provides guidance on the new System.Diagnostics.Process APIs introduced in .NET 11: Process.Run, Process.RunAndCaptureText, Process.StartAndForget, Process.ReadAllText\u002FBytes\u002FLines, KillOnParentExit, InheritedHandles, and StartDetached. USE FOR: starting, orchestrating, or capturing output from external processes in applications targeting net11.0 or later. DO NOT USE FOR: applications targeting .NET 10 or earlier, or basic pre-.NET 11 Process.Start usage without new APIs.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fprocess-api-net11\u002FSKILL.md",[215,216],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},{"categoryNo":95,"categoryName":96,"taxonomyType":97,"taxonomyTypeDesc":98},[108,218,219,220,103,221,156,190,161,201,202,32,222,223,224,225,206,169,226],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]