[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DZM5G5NHDWHSDFGFPRC7K1":3,"skill-same:01M6DZM5G5NHDWHSDFGFPRC7K1":76},{"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":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6DZM5G5NHDWHSDFGFPRC7K1","migrate-xunit-to-xunit-v3",null,"Migrate .NET test projects from xUnit.net v2 to xunit.v3 and fix v3 breaks. Use for package\u002FCPM conversion, OutputType=Exe, preserving the VSTest or MTP runner (including projects currently using YTest.MTP.XUnit2), incompatible TFMs, async void tests, string-to-Type attributes, custom Fact\u002FTheory\u002FBeforeAfterTest attributes, Xunit.SkippableFact, xunit.abstractions\u002Fextensibility consolidation, and Xunit.Combinatorial\u002FStaFact compatibility. Do not use for framework conversion or a runner-only migration. For xUnit v3 MTP filter syntax, also use migrate-vstest-to-mtp.","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-xunit-to-xunit-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,42,43,44,45],"migrate","migrate xunit to xunit v3","xunit","v3","async","void","attributes","consolidation","filter","CPM","STRING","type","tests","runner","do","compatibility","test","conversion","migration","only","use","fix","syntax","projects","package","framework","filter syntax","2026-11-10 10:12:30",false,"---\nname: migrate-xunit-to-xunit-v3\ndescription: >\n  Migrate .NET test projects from xUnit.net v2 to xunit.v3 and fix v3 breaks.\n  Use for package\u002FCPM conversion, OutputType=Exe, preserving the VSTest or MTP\n  runner (including projects currently using YTest.MTP.XUnit2), incompatible\n  TFMs, async void tests,\n  string-to-Type attributes, custom Fact\u002FTheory\u002FBeforeAfterTest attributes,\n  Xunit.SkippableFact, xunit.abstractions\u002Fextensibility consolidation, and\n  Xunit.Combinatorial\u002FStaFact compatibility. Do not use for framework\n  conversion or a runner-only migration. For xUnit v3 MTP filter syntax, also\n  use migrate-vstest-to-mtp.\nlicense: MIT\n---\n\n# xunit.v3 Migration\n\nMigrate .NET test projects from xUnit.net v2 to xUnit.net v3. The outcome is a solution where all test projects reference `xunit.v3.*` packages, compiles cleanly, and all tests pass with the same results as before migration.\n\n## When to Use\n\n- Upgrading test projects from `xunit` (v2) packages to `xunit.v3`\n- Resolving compilation errors after updating xunit package references to v3\n\n## When Not to Use\n\n- Migrating between test frameworks (e.g., MSTest or NUnit to xUnit.net) — different effort entirely\n- Migrating from VSTest to Microsoft.Testing.Platform — use `migrate-vstest-to-mtp`\n- The projects already reference `xunit.v3` — migration is done\n\n## Inputs\n\n| Input | Required | Description |\n|-------|----------|-------------|\n| Test project or solution | No | Discover `.csproj`, `.sln`, `.slnx`, central props, and source in the current working directory; ask only if none are found or the target is ambiguous |\n\n## Workspace and Completion Contract\n\n- Skill activation is not completion. For migrate\u002Ffix\u002Fupdate requests, inspect\n  the staged files, edit them, and run tests in the same task.\n- The skill base directory contains only guidance. Search the current working\n  directory and open paths exactly as returned.\n- If a tool rejects a searched path, classify the rejection before retrying.\n  Only a positively confirmed reader\u002Fpath-normalization limitation with\n  authorized access permits retrying through another permitted reader\u002Feditor.\n- On a permission, policy, or content-exclusion denial, stop that path and\n  report the blocker. Never bypass the denial through other tools, shell\n  commands, aliases, or agents, or infer or reconstruct the restricted content.\n- If the rejection reason is unclear, treat the path as unavailable, not\n  missing. Continue only independently permitted work and explicitly disclose\n  the incomplete migration.\n- Do not ask the user to provide a path while workspace discovery can find it.\n- Inventory project\u002Fcentral package files and all affected source in one pass.\n  A package-only migration is incomplete when v2-only APIs remain.\n- End with the detected source version and runner, exact package compatibility\n  set, files changed, discovered\u002Fpassed\u002Ffailed\u002Fskipped counts, and any\n  platform-specific result. A build without test discovery is not success.\n- Package validity is empirical: record the configured feed query or resolved\n  package graph and a successful restore. In the final result, say how the\n  selected exact versions were proven available; do not merely name a version\n  and leave a judge or user to infer whether it exists.\n\n## Workflow\n\n> **Commit strategy:** Do not create commits unless the user asks. Keep project\n> configuration and source edits logically separable in the diff, but finish\n> and verify the whole requested migration.\n\n> **Prioritization:** Steps 1-5 are required for every migration. Steps 6-12 are conditional — only apply the ones relevant to the project's code patterns. Skip steps that don't apply.\n\n### Decisions that change the result\n\nRun this preflight before editing:\n\n| Detected state | Required action |\n|---|---|\n| Project references `xunit.v3`, has the required executable\u002Frunner configuration, contains no remaining v2 packages or v2-only API patterns, and its existing test command passes | Stop: migration is already complete. Do not update versions, create props files, or modify source. Report the verified no-op result. If any required v3 adaptation remains, make only that repair instead of treating the package reference alone as completion. |\n| xUnit v2 uses `YTest.MTP.XUnit2` | Preserve MTP: remove that shim, set `UseMicrosoftTestingPlatformRunner=true`, and do not add `xunit.runner.visualstudio` or `IsTestingPlatformApplication=false`. |\n| xUnit v2 does not use the MTP shim | Preserve VSTest: keep\u002Fupdate `xunit.runner.visualstudio` and set `IsTestingPlatformApplication=false`. |\n| A custom type derives from `BeforeAfterTestAttribute` | Preserve that inheritance and its behavior. Add the `IXunitTest` parameter to both overrides and pass it to `base.Before`\u002F`base.After`; do not replace the subclass with a direct interface implementation. |\n| A Type-based collection\u002Forderer attribute points to a custom type | Migrate both the attribute syntax and the referenced type's v3 contract. For a collection factory, implement the required xUnit v3 `IXunitTestCollectionFactory` behavior; compiling the attribute while leaving an empty factory is not a complete migration. |\n| Companion packages are present | Resolve `xunit.v3`, Xunit.Combinatorial, and Xunit.StaFact as one compatible set from configured feeds. If the newest xunit.v3 major has no compatible stable companion on those feeds, select the newest compatible xunit.v3 major and explain the pin. Validate discovery, not just compilation. |\n| `OutputType=Exe` makes a `net*-windows` project fail on a non-Windows host | Add `EnableWindowsTargeting=true` when cross-building is intended, then rerun. Do not dismiss this migration-induced failure as pre-existing. |\n\nResolve package versions from the configured package source. Do not guess a\nversion from the product's \"v3\" name or update unrelated packages. Change only\nfiles that contain a package, property, or source construct required by the\napplicable rule.\n\nAfter editing a Central Package Management project, read back both\n`Directory.Packages.props` and the project file. Confirm that `PackageVersion`\nowns the version, the renamed `PackageReference` is versionless, and\n`OutputType=Exe` is effective.\n\n### Step 1: Identify xUnit.net projects and verify compatibility\n\nSearch for test projects referencing xUnit.net v2 packages:\n\n- `xunit`\n- `xunit.abstractions`\n- `xunit.assert`\n- `xunit.core`\n- `xunit.extensibility.core`\n- `xunit.extensibility.execution`\n- `xunit.runner.visualstudio`\n\nMake sure to check the package references in project files, MSBuild props and targets files, like `Directory.Build.props`, `Directory.Build.targets`, and `Directory.Packages.props`.\n\nVerify target framework compatibility: xUnit.net v3 requires **.NET 8+** or **.NET Framework 4.7.2+**. For test library projects, .NET Standard 2.0 is also supported. If any test projects have non-compatible target frameworks, STOP here — tell the user to upgrade the target framework first. Also verify the project uses SDK-style format.\n\n### Step 2: Update package references\n\n1. Update any `PackageReference` or `PackageVersion` items for the new package names, based on the following mapping:\n\n    - `xunit` → `xunit.v3`\n    - `xunit.abstractions` → Remove entirely\n    - `xunit.assert` → `xunit.v3.assert`\n    - `xunit.core` → `xunit.v3.core`\n    - `xunit.extensibility.core` and `xunit.extensibility.execution` → `xunit.v3.extensibility.core` (if both are referenced in a project consolidate to only a single entry as the two packages are merged)\n\n2. Query the configured package source and pin the latest stable versions that actually exist. Also update `xunit.runner.visualstudio` only for VSTest projects; do not add it to MTP projects.\n\n### Step 3: Set `OutputType` to `Exe`\n\nIn each test project (excluding test library projects), set `OutputType` to `Exe` in the project file:\n\n```xml\n\u003CPropertyGroup>\n  \u003COutputType>Exe\u003C\u002FOutputType>\n\u003C\u002FPropertyGroup>\n```\n\nDepending on the solution in hand, there might be a centralized place where this can be added. For example:\n\n- If all test projects share (or can share) a common `Directory.Build.props`, add the `\u003COutputType>Exe\u003C\u002FOutputType>` property there. Note that the OutputType should not be added to `Directory.Build.targets`.\n- If all test projects share a name pattern (e.g., `*.Tests.csproj`), add a conditional property group in `Directory.Build.props` that applies only to those projects, like `\u003COutputType Condition=\"$(MSBuildProjectName.EndsWith('.Tests'))\">Exe\u003C\u002FOutputType>`. Adjust the condition as needed to target only test projects.\n- Otherwise, add the `\u003COutputType>Exe\u003C\u002FOutputType>` property to each test project file individually.\n\n### Step 4: Configure test platform\n\nPreserve the same test platform that was used with xUnit.net v2. xUnit.net v2 always uses VSTest except if the project used `YTest.MTP.XUnit2`.\n\n- If the project had a reference to `YTest.MTP.XUnit2`:\n  - Remove the reference to `YTest.MTP.XUnit2` completely.\n  - Set `\u003CUseMicrosoftTestingPlatformRunner>true\u003C\u002FUseMicrosoftTestingPlatformRunner>` in an existing shared `Directory.Build.props`, or in the test project when no shared props file exists.\n  - Do not add `xunit.runner.visualstudio`; it is a VSTest runner and weakens platform preservation.\n- If the project did NOT reference `YTest.MTP.XUnit2` (the common case):\n  - Set `\u003CIsTestingPlatformApplication>false\u003C\u002FIsTestingPlatformApplication>` in an existing shared `Directory.Build.props`, or directly in the test project when no shared props file exists. Do not create a repository-wide props file solely for one project. This keeps the project on VSTest.\n\n### Step 5: Remove `Xunit.Abstractions` usings\n\nFind any `using Xunit.Abstractions;` directives in C# files and remove them completely.\n\n### Step 6: Address `async void` breaking change (if applicable)\n\nIn xUnit.net v3, `async void` test methods are no longer supported and will fail to compile. Search for any test methods declared with `async void` and change them to `async Task`. Test methods can be identified via the `[Fact]` or `[Theory]` attributes or other test attributes.\n\nIn the final result, state why the source changed: xUnit.net v3 rejects\n`async void` tests, so each affected method now returns `Task`. Do not report\nonly the mechanical replacement. Also state how the exact package versions were\nresolved from the configured feed.\n\n### Step 7: Address breaking change of attributes (if applicable)\n\nIn xUnit.net v3, some attributes were updated so that they accept a `System.Type` instead of two strings (fully qualified type name and assembly name). These attributes are:\n\n- `CollectionBehaviorAttribute`\n- `TestCaseOrdererAttribute`\n- `TestCollectionOrdererAttribute`\n- `TestFrameworkAttribute`\n\nFor example, `[assembly: CollectionBehavior(\"MyNamespace.MyCollectionFactory\", \"MyAssembly\")]` must be converted to `[assembly: CollectionBehavior(typeof(MyNamespace.MyCollectionFactory))]`.\n\n### Step 8: Inheriting from FactAttribute or TheoryAttribute (if applicable)\n\nIdentify if there are any custom attributes that inherit from `FactAttribute` or `TheoryAttribute`. These custom user-defined attributes must now provide source information. For example, if the attribute looked like this:\n\n```csharp\ninternal sealed class MyFactAttribute : FactAttribute\n{\n    public MyFactAttribute()\n    {\n    }\n}\n```\n\nit must be changed to this:\n\n```csharp\ninternal sealed class MyFactAttribute : FactAttribute\n{\n    public MyFactAttribute(\n        [CallerFilePath] string? sourceFilePath = null,\n        [CallerLineNumber] int sourceLineNumber = -1\n    ) : base(sourceFilePath, sourceLineNumber)\n    {\n    }\n}\n```\n\nBefore reporting completion, read back every affected `FactAttribute`- and\n`TheoryAttribute`-derived constructor. Name each type and confirm that both\ncaller-info parameters and the corresponding `base(sourceFilePath,\nsourceLineNumber)` forwarding are present. A passing test run alone does not\nprove source information was propagated.\n\n### Step 9: Inheriting from BeforeAfterTestAttribute (if applicable)\n\nIdentify if there are any custom attributes that inherit from `BeforeAfterTestAttribute`. These custom user-defined attributes must update their method signatures. Previously, they would have `Before`\u002F`After` overrides that look like this:\n\n```csharp\n    public override void Before(MethodInfo methodUnderTest)\n    {\n        \u002F\u002F Possibly some custom logic here\n        base.Before(methodUnderTest);\n        \u002F\u002F Possibly some custom logic here\n    }\n\n    public override void After(MethodInfo methodUnderTest)\n    {\n        \u002F\u002F Possibly some custom logic here\n        base.After(methodUnderTest);\n        \u002F\u002F Possibly some custom logic here\n    }\n```\n\nit must be changed to this:\n\n```csharp\n    public override void Before(MethodInfo methodUnderTest, IXunitTest test)\n    {\n        \u002F\u002F Possibly some custom logic here\n        base.Before(methodUnderTest, test);\n        \u002F\u002F Possibly some custom logic here\n    }\n\n    public override void After(MethodInfo methodUnderTest, IXunitTest test)\n    {\n        \u002F\u002F Possibly some custom logic here\n        base.After(methodUnderTest, test);\n        \u002F\u002F Possibly some custom logic here\n    }\n```\n\nKeep the `BeforeAfterTestAttribute` base class, retain the override modifiers, and preserve the\nexisting base calls and their ordering relative to custom logic. Implementing\n`IBeforeAfterTestAttribute` directly may compile, but it is not the mechanical v2-to-v3 migration\nand can discard base-class behavior.\n\nBefore reporting completion, read the resulting attribute file and quote the\nactual `Before(MethodInfo, IXunitTest)` and `After(MethodInfo, IXunitTest)`\nsignatures. Explicitly confirm that both `base.Before` and `base.After` receive\nthe same `IXunitTest` argument; a generic claim that the overrides were updated\nis insufficient evidence.\n\n### Step 10: Address new xUnit analyzer warnings (if applicable)\n\nxunit.v3 introduced new analyzer warnings. The most notable is xUnit1051 (use `TestContext.Current.CancellationToken` for methods accepting `CancellationToken`). Address these if present.\n\n### Step 11: Migrate `Xunit.SkippableFact` (if applicable)\n\nIf there are any package references to `Xunit.SkippableFact`, remove all these package references entirely.\n\nThen, follow these steps to eliminate usages of APIs coming from the removed package reference:\n\n- Update any `SkippableFact` attribute to the regular `Fact` attribute.\n- Update any `SkippableTheory` attribute to the regular `Theory` attribute.\n- Change `Skip.If` method calls to `Assert.SkipWhen`.\n- Change `Skip.IfNot` method calls to `Assert.SkipUnless`.\n\nVerify both branches when the fixture makes that practical: the default\ncondition should report the intended skip reason, and the enabled condition\nshould execute and pass. A grep plus a generic passing run does not prove the\nruntime skip semantics were preserved.\n\nLimit this conversion to the existing project\u002Fcentral-package file and the source files containing\nthese APIs. Do not create a new `Directory.Build.props` merely to perform this companion-package\nmigration; any required runner property belongs in the existing test project when no shared props\nfile already exists.\n\n### Step 12: Update companion packages (if applicable)\n\n- Query the configured feeds for a mutually compatible set instead of resolving\n  each package independently. `Xunit.Combinatorial` 1.x moves to 2.x or later,\n  and `Xunit.StaFact` 1.x moves to a line compatible with the selected\n  `xunit.v3` major.\n- Do not infer companion compatibility from the product name or matching major\n  numbers. Use package dependency constraints and the versions available on the\n  configured feeds, then prove the selected set through test discovery.\n- On `net*-windows` projects built from Linux\u002FmacOS after switching to\n  executable output, set `EnableWindowsTargeting=true` if cross-targeting is\n  intended.\n- Run tests and confirm expected platform skips (such as STA tests on Linux)\n  separately from failures.\n\n### Step 13: Build and verify\n\nBuild the solution and fix any remaining compilation errors. Run `dotnet test` to verify all tests pass with the same results as before migration.\n","# xunit.v3 Migration\n\nMigrate .NET test projects from xUnit.net v2 to xUnit.net v3. The outcome is a solution where all test projects reference `xunit.v3.*` packages, compiles cleanly, and all tests pass with the same results as before migration.\n\n## When to Use\n\n- Upgrading test projects from `xunit` (v2) packages to `xunit.v3`\n- Resolving compilation errors after updating xunit package references to v3\n\n## When Not to Use\n\n- Migrating between test frameworks (e.g., MSTest or NUnit to xUnit.net) — different effort entirely\n- Migrating from VSTest to Microsoft.Testing.Platform — use `migrate-vstest-to-mtp`\n- The projects already reference `xunit.v3` — migration is done\n\n## Inputs\n\n| Input | Required | Description |\n|-------|----------|-------------|\n| Test project or solution | No | Discover `.csproj`, `.sln`, `.slnx`, central props, and source in the current working directory; ask only if none are found or the target is ambiguous |\n\n## Workspace and Completion Contract\n\n- Skill activation is not completion. For migrate\u002Ffix\u002Fupdate requests, inspect\n  the staged files, edit them, and run tests in the same task.\n- The skill base directory contains only guidance. Search the current working\n  directory and open paths exactly as returned.\n- If a tool rejects a searched path, classify the rejection before retrying.\n  Only a positively confirmed reader\u002Fpath-normalization limitation with\n  authorized access permits retrying through another permitted reader\u002Feditor.\n- On a permission, policy, or content-exclusion denial, stop that path and\n  report the blocker. Never bypass the denial through other tools, shell\n  commands, aliases, or agents, or infer or reconstruct the restricted content.\n- If the rejection reason is unclear, treat the path as unavailable, not\n  missing. Continue only independently permitted work and explicitly disclose\n  the incomplete migration.\n- Do not ask the user to provide a path while workspace discovery can find it.\n- Inventory project\u002Fcentral package files and all affected source in one pass.\n  A package-only migration is incomplete when v2-only APIs remain.\n- End with the detected source version and runner, exact package compatibility\n  set, files changed, discovered\u002Fpassed\u002Ffailed\u002Fskipped counts, and any\n  platform-specific result. A build without test discovery is not success.\n- Package validity is empirical: record the configured feed query or resolved\n  package graph and a successful restore. In the final result, say how the\n  selected exact versions were proven available; do not merely name a version\n  and leave a judge or user to infer whether it exists.\n\n## Workflow\n\n> **Commit strategy:** Do not create commits unless the user asks. Keep project\n> configuration and source edits logically separable in the diff, but finish\n> and verify the whole requested migration.\n\n> **Prioritization:** Steps 1-5 are required for every migration. Steps 6-12 are conditional — only apply the ones relevant to the project's code patterns. Skip steps that don't apply.\n\n### Decisions that change the result\n\nRun this preflight before editing:\n\n| Detected state | Required action |\n|---|---|\n| Project references `xunit.v3`, has the required executable\u002Frunner configuration, contains no remaining v2 packages or v2-only API patterns, and its existing test command passes | Stop: migration is already complete. Do not update versions, create props files, or modify source. Report the verified no-op result. If any required v3 adaptation remains, make only that repair instead of treating the package reference alone as completion. |\n| xUnit v2 uses `YTest.MTP.XUnit2` | Preserve MTP: remove that shim, set `UseMicrosoftTestingPlatformRunner=true`, and do not add `xunit.runner.visualstudio` or `IsTestingPlatformApplication=false`. |\n| xUnit v2 does not use the MTP shim | Preserve VSTest: keep\u002Fupdate `xunit.runner.visualstudio` and set `IsTestingPlatformApplication=false`. |\n| A custom type derives from `BeforeAfterTestAttribute` | Preserve that inheritance and its behavior. Add the `IXunitTest` parameter to both overrides and pass it to `base.Before`\u002F`base.After`; do not replace the subclass with a direct interface implementation. |\n| A Type-based collection\u002Forderer attribute points to a custom type | Migrate both the attribute syntax and the referenced type's v3 contract. For a collection factory, implement the required xUnit v3 `IXunitTestCollectionFactory` behavior; compiling the attribute while leaving an empty factory is not a complete migration. |\n| Companion packages are present | Resolve `xunit.v3`, Xunit.Combinatorial, and Xunit.StaFact as one compatible set from configured feeds. If the newest xunit.v3 major has no compatible stable companion on those feeds, select the newest compatible xunit.v3 major and explain the pin. Validate discovery, not just compilation. |\n| `OutputType=Exe` makes a `net*-windows` project fail on a non-Windows host | Add `EnableWindowsTargeting=true` when cross-building is intended, then rerun. Do not dismiss this migration-induced failure as pre-existing. |\n\nResolve package versions from the configured package source. Do not guess a\nversion from the product's \"v3\" name or update unrelated packages. Change only\nfiles that contain a package, property, or source construct required by the\napplicable rule.\n\nAfter editing a Central Package Management project, read back both\n`Directory.Packages.props` and the project file. Confirm that `PackageVersion`\nowns the version, the renamed `PackageReference` is versionless, and\n`OutputType=Exe` is effective.\n\n### Step 1: Identify xUnit.net projects and verify compatibility\n\nSearch for test projects referencing xUnit.net v2 packages:\n\n- `xunit`\n- `xunit.abstractions`\n- `xunit.assert`\n- `xunit.core`\n- `xunit.extensibility.core`\n- `xunit.extensibility.execution`\n- `xunit.runner.visualstudio`\n\nMake sure to check the package references in project files, MSBuild props and targets files, like `Directory.Build.props`, `Directory.Build.targets`, and `Directory.Packages.props`.\n\nVerify target framework compatibility: xUnit.net v3 requires **.NET 8+** or **.NET Framework 4.7.2+**. For test library projects, .NET Standard 2.0 is also supported. If any test projects have non-compatible target frameworks, STOP here — tell the user to upgrade the target framework first. Also verify the project uses SDK-style format.\n\n### Step 2: Update package references\n\n1. Update any `PackageReference` or `PackageVersion` items for the new package names, based on the following mapping:\n\n    - `xunit` → `xunit.v3`\n    - `xunit.abstractions` → Remove entirely\n    - `xunit.assert` → `xunit.v3.assert`\n    - `xunit.core` → `xunit.v3.core`\n    - `xunit.extensibility.core` and `xunit.extensibility.execution` → `xunit.v3.extensibility.core` (if both are referenced in a project consolidate to only a single entry as the two packages are merged)\n\n2. Query the configured package source and pin the latest stable versions that actually exist. Also update `xunit.runner.visualstudio` only for VSTest projects; do not add it to MTP projects.\n\n### Step 3: Set `OutputType` to `Exe`\n\nIn each test project (excluding test library projects), set `OutputType` to `Exe` in the project file:\n\n```xml\n\u003CPropertyGroup>\n  \u003COutputType>Exe\u003C\u002FOutputType>\n\u003C\u002FPropertyGroup>\n```\n\nDepending on the solution in hand, there might be a centralized place where this can be added. For example:\n\n- If all test projects share (or can share) a common `Directory.Build.props`, add the `\u003COutputType>Exe\u003C\u002FOutputType>` property there. Note that the OutputType should not be added to `Directory.Build.targets`.\n- If all test projects share a name pattern (e.g., `*.Tests.csproj`), add a conditional property group in `Directory.Build.props` that applies only to those projects, like `\u003COutputType Condition=\"$(MSBuildProjectName.EndsWith('.Tests'))\">Exe\u003C\u002FOutputType>`. Adjust the condition as needed to target only test projects.\n- Otherwise, add the `\u003COutputType>Exe\u003C\u002FOutputType>` property to each test project file individually.\n\n### Step 4: Configure test platform\n\nPreserve the same test platform that was used with xUnit.net v2. xUnit.net v2 always uses VSTest except if the project used `YTest.MTP.XUnit2`.\n\n- If the project had a reference to `YTest.MTP.XUnit2`:\n  - Remove the reference to `YTest.MTP.XUnit2` completely.\n  - Set `\u003CUseMicrosoftTestingPlatformRunner>true\u003C\u002FUseMicrosoftTestingPlatformRunner>` in an existing shared `Directory.Build.props`, or in the test project when no shared props file exists.\n  - Do not add `xunit.runner.visualstudio`; it is a VSTest runner and weakens platform preservation.\n- If the project did NOT reference `YTest.MTP.XUnit2` (the common case):\n  - Set `\u003CIsTestingPlatformApplication>false\u003C\u002FIsTestingPlatformApplication>` in an existing shared `Directory.Build.props`, or directly in the test project when no shared props file exists. Do not create a repository-wide props file solely for one project. This keeps the project on VSTest.\n\n### Step 5: Remove `Xunit.Abstractions` usings\n\nFind any `using Xunit.Abstractions;` directives in C# files and remove them completely.\n\n### Step 6: Address `async void` breaking change (if applicable)\n\nIn xUnit.net v3, `async void` test methods are no longer supported and will fail to compile. Search for any test methods declared with `async void` and change them to `async Task`. Test methods can be identified via the `[Fact]` or `[Theory]` attributes or other test attributes.\n\nIn the final result, state why the source changed: xUnit.net v3 rejects\n`async void` tests, so each affected method now returns `Task`. Do not report\nonly the mechanical replacement. Also state how the exact package versions were\nresolved from the configured feed.\n\n### Step 7: Address breaking change of attributes (if applicable)\n\nIn xUnit.net v3, some attributes were updated so that they accept a `System.Type` instead of two strings (fully qualified type name and assembly name). These attributes are:\n\n- `CollectionBehaviorAttribute`\n- `TestCaseOrdererAttribute`\n- `TestCollectionOrdererAttribute`\n- `TestFrameworkAttribute`\n\nFor example, `[assembly: CollectionBehavior(\"MyNamespace.MyCollectionFactory\", \"MyAssembly\")]` must be converted to `[assembly: CollectionBehavior(typeof(MyNamespace.MyCollectionFactory))]`.\n\n### Step 8: Inheriting from FactAttribute or TheoryAttribute (if applicable)\n\nIdentify if there are any custom attributes that inherit from `FactAttribute` or `TheoryAttribute`. These custom user-defined attributes must now provide source information. For example, if the attribute looked like this:\n\n```csharp\ninternal sealed class MyFactAttribute : FactAttribute\n{\n    public MyFactAttribute()\n    {\n    }\n}\n```\n\nit must be changed to this:\n\n```csharp\ninternal sealed class MyFactAttribute : FactAttribute\n{\n    public MyFactAttribute(\n        [CallerFilePath] string? sourceFilePath = null,\n        [CallerLineNumber] int sourceLineNumber = -1\n    ) : base(sourceFilePath, sourceLineNumber)\n    {\n    }\n}\n```\n\nBefore reporting completion, read back every affected `FactAttribute`- and\n`TheoryAttribute`-derived constructor. Name each type and confirm that both\ncaller-info parameters and the corresponding `base(sourceFilePath,\nsourceLineNumber)` forwarding are present. A passing test run alone does not\nprove source information was propagated.\n\n### Step 9: Inheriting from BeforeAfterTestAttribute (if applicable)\n\nIdentify if there are any custom attributes that inherit from `BeforeAfterTestAttribute`. These custom user-defined attributes must update their method signatures. Previously, they would have `Before`\u002F`After` overrides that look like this:\n\n```csharp\n    public override void Before(MethodInfo methodUnderTest)\n    {\n        \u002F\u002F Possibly some custom logic here\n        base.Before(methodUnderTest);\n        \u002F\u002F Possibly some custom logic here\n    }\n\n    public override void After(MethodInfo methodUnderTest)\n    {\n        \u002F\u002F Possibly some custom logic here\n        base.After(methodUnderTest);\n        \u002F\u002F Possibly some custom logic here\n    }\n```\n\nit must be changed to this:\n\n```csharp\n    public override void Before(MethodInfo methodUnderTest, IXunitTest test)\n    {\n        \u002F\u002F Possibly some custom logic here\n        base.Before(methodUnderTest, test);\n        \u002F\u002F Possibly some custom logic here\n    }\n\n    public override void After(MethodInfo methodUnderTest, IXunitTest test)\n    {\n        \u002F\u002F Possibly some custom logic here\n        base.After(methodUnderTest, test);\n        \u002F\u002F Possibly some custom logic here\n    }\n```\n\nKeep the `BeforeAfterTestAttribute` base class, retain the override modifiers, and preserve the\nexisting base calls and their ordering relative to custom logic. Implementing\n`IBeforeAfterTestAttribute` directly may compile, but it is not the mechanical v2-to-v3 migration\nand can discard base-class behavior.\n\nBefore reporting completion, read the resulting attribute file and quote the\nactual `Before(MethodInfo, IXunitTest)` and `After(MethodInfo, IXunitTest)`\nsignatures. Explicitly confirm that both `base.Before` and `base.After` receive\nthe same `IXunitTest` argument; a generic claim that the overrides were updated\nis insufficient evidence.\n\n### Step 10: Address new xUnit analyzer warnings (if applicable)\n\nxunit.v3 introduced new analyzer warnings. The most notable is xUnit1051 (use `TestContext.Current.CancellationToken` for methods accepting `CancellationToken`). Address these if present.\n\n### Step 11: Migrate `Xunit.SkippableFact` (if applicable)\n\nIf there are any package references to `Xunit.SkippableFact`, remove all these package references entirely.\n\nThen, follow these steps to eliminate usages of APIs coming from the removed package reference:\n\n- Update any `SkippableFact` attribute to the regular `Fact` attribute.\n- Update any `SkippableTheory` attribute to the regular `Theory` attribute.\n- Change `Skip.If` method calls to `Assert.SkipWhen`.\n- Change `Skip.IfNot` method calls to `Assert.SkipUnless`.\n\nVerify both branches when the fixture makes that practical: the default\ncondition should report the intended skip reason, and the enabled condition\nshould execute and pass. A grep plus a generic passing run does not prove the\nruntime skip semantics were preserved.\n\nLimit this conversion to the existing project\u002Fcentral-package file and the source files containing\nthese APIs. Do not create a new `Directory.Build.props` merely to perform this companion-package\nmigration; any required runner property belongs in the existing test project when no shared props\nfile already exists.\n\n### Step 12: Update companion packages (if applicable)\n\n- Query the configured feeds for a mutually compatible set instead of resolving\n  each package independently. `Xunit.Combinatorial` 1.x moves to 2.x or later,\n  and `Xunit.StaFact` 1.x moves to a line compatible with the selected\n  `xunit.v3` major.\n- Do not infer companion compatibility from the product name or matching major\n  numbers. Use package dependency constraints and the versions available on the\n  configured feeds, then prove the selected set through test discovery.\n- On `net*-windows` projects built from Linux\u002FmacOS after switching to\n  executable output, set `EnableWindowsTargeting=true` if cross-targeting is\n  intended.\n- Run tests and confirm expected platform skips (such as STA tests on Linux)\n  separately from failures.\n\n### Step 13: Build and verify\n\nBuild the solution and fix any remaining compilation errors. Run `dotnet test` to verify all tests pass with the same results as before migration.\n",{"name":5,"license":15,"description":51},"Migrate .NET test projects from xUnit.net v2 to xunit.v3 and fix v3 breaks. Use for package\u002FCPM conversion, OutputType=Exe, preserving the VSTest or MTP runner (including projects currently using YTest.MTP.XUnit2), incompatible TFMs, async void tests, string-to-Type attributes, custom Fact\u002FTheory\u002FBeforeAfterTest attributes, Xunit.SkippableFact, xunit.abstractions\u002Fextensibility consolidation, and Xunit.Combinatorial\u002FStaFact compatibility. Do not use for framework conversion or a runner-only migration. For xUnit v3 MTP filter syntax, also use migrate-vstest-to-mtp.\n","main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","external-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-test-migration\u002Fskills\u002Fmigrate-xunit-to-xunit-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":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add managedcode\u002Fdotnet-skills --skill migrate-xunit-to-xunit-v3",{"tool":68,"command":69},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill migrate-xunit-to-xunit-v3",{"tool":71,"command":72},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill migrate-xunit-to-xunit-v3","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-test-migration\u002Fskills\u002Fmigrate-xunit-to-xunit-v3\u002FSKILL.md",true,[],[77,114,138,168,178,203],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":93,"publishedAt":46},"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",[83,88],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113],"xtwitter scraper","browser automation","workflows","run","code","browser","search","repository","api","Media","api client","access","edit","unrelated","webhooks","files","social","commands","modeling","webhook",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":126,"publishedAt":46},"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",[120,123],{"categoryNo":121,"categoryName":122,"taxonomyType":86,"taxonomyTypeDesc":87},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":124,"categoryName":125,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000036","内容创作者",[116,127,128,96,129,97,101,130,131,132,106,133,107,109,33,134,135,136,111,137],"writing","performance","tasks","data","parsing","parser","context","writer","options","project","high-performance",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":46},"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",[],[145,146,147,148,149,150,151,152,153,154,41,155,39,156,157,158,159,160,161,162,163,164,165,166,167],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","node","guide","language","three","compute","post","processing","with","renderer","for","materials","wgsl","effects","when",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":46},"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",[],[170,39,109,175,176,163,177],"semantic","razor","inspection",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":46},"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",[],[185,186,187,188,127,189,190,191,192,193,194,39,38,195,196,197,33,30,198,199,200,163,201,202,167],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","probe","guidance","later","dictionary","naming","targeting","custom","generic",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":211,"publishedAt":46},"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",[209,210],{"categoryNo":84,"categoryName":85,"taxonomyType":86,"taxonomyTypeDesc":87},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[102,212,213,214,97,215,152,185,39,196,197,33,216,217,218,219,200,163,220],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]