[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DZQZPYYG0B78ZA7E7DE173":3,"skill-same:01M6DZQZPYYG0B78ZA7E7DE173":96},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6DZQZPYYG0B78ZA7E7DE173","thread-abort-migration",null,"Guides migration of .NET Framework Thread.Abort usage to cooperative cancellation in modern .NET. USE FOR: modernizing code that calls Thread.Abort, catching ThreadAbortException, replacing Thread.ResetAbort, replacing Thread.Interrupt for thread termination, resolving PlatformNotSupportedException or SYSLIB0006 after retargeting to .NET 6+, migrating ASP.NET Response.End or Response.Redirect(url, true) which internally call Thread.Abort. DO NOT USE FOR: code that only uses Thread.Join, Thread.Sleep, or Thread.Start without any abort, interrupt, or ThreadAbortException usage — these APIs work identically in modern .NET and need no migration. Also not for projects staying on .NET Framework, or Thread.Abort usage inside third-party libraries you do not control.","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",514,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-upgrade\u002Fskills\u002Fthread-abort-migration\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],"thread","migration","thread abort migration","third-party","which","retargeting","usage","you","URL","sleep","guides","join","end","libraries","control","call","do","only","use","work","projects","start","framework","code","2026-11-10 10:12:30",false,"---\nname: thread-abort-migration\ndescription: >\n  Guides migration of .NET Framework Thread.Abort usage to cooperative cancellation\n  in modern .NET.\n  USE FOR: modernizing code that calls Thread.Abort, catching ThreadAbortException,\n  replacing Thread.ResetAbort, replacing Thread.Interrupt for thread termination,\n  resolving PlatformNotSupportedException or SYSLIB0006 after retargeting to .NET 6+,\n  migrating ASP.NET Response.End or Response.Redirect(url, true) which internally\n  call Thread.Abort.\n  DO NOT USE FOR: code that only uses Thread.Join, Thread.Sleep, or Thread.Start\n  without any abort, interrupt, or ThreadAbortException usage — these APIs work\n  identically in modern .NET and need no migration. Also not for projects staying\n  on .NET Framework, or Thread.Abort usage inside third-party libraries you do not\n  control.\nlicense: MIT\n---\n\n# Thread.Abort Migration\n\nThis skill helps an agent migrate .NET Framework code that uses `Thread.Abort` to the cooperative cancellation model required by modern .NET (6+). `Thread.Abort` throws `PlatformNotSupportedException` in modern .NET — there is no way to forcibly terminate a managed thread. The skill identifies the usage pattern first, then applies the correct replacement strategy.\n\n## When to Use\n\n- Migrating a .NET Framework project to .NET 6+ that calls `Thread.Abort`\n- Replacing `ThreadAbortException` catch blocks that use control flow or cleanup logic\n- Removing `Thread.ResetAbort` calls that cancel pending aborts\n- Replacing `Thread.Interrupt` for waking blocked threads\n- Migrating ASP.NET code that uses `Response.End` or `Response.Redirect(url, true)`, which internally call `Thread.Abort`\n- Resolving `PlatformNotSupportedException` or `SYSLIB0006` warnings after a target framework change\n\n## When Not to Use\n\n- **The code only uses `Thread.Join`, `Thread.Sleep`, or `Thread.Start` without any abort, interrupt, or `ThreadAbortException` catch blocks.** These APIs work identically in modern .NET — no migration is needed. Stop here and tell the user no migration is required. If you suggest modernization (e.g., `Task.Run`, `Parallel.ForEach`), you **must** explicitly state these are optional improvements unrelated to Thread.Abort migration, and the existing code will compile and run correctly as-is on the target framework.\n- The project will remain on .NET Framework indefinitely\n- The Thread.Abort usage is inside a third-party library you do not control\n\n## Inputs\n\n| Input | Required | Description |\n|-------|----------|-------------|\n| Source project or solution | Yes | The .NET Framework project containing Thread.Abort usage |\n| Target framework | Yes | The modern .NET version to target (e.g., `net8.0`) |\n| Thread.Abort usage locations | Recommended | Files or classes that reference `Thread.Abort`, `ThreadAbortException`, `Thread.ResetAbort`, or `Thread.Interrupt` |\n\n## Workflow\n\n> **Commit strategy:** Commit after each pattern replacement so the migration is reviewable and bisectable. Group related call sites (e.g., all cancellable work loops) into one commit.\n\n### Step 1: Inventory all thread termination usage\n\nSearch the codebase for all thread-termination-related APIs:\n\n- `Thread.Abort` and `thread.Abort()` (instance calls)\n- `ThreadAbortException` in catch blocks\n- `Thread.ResetAbort`\n- `Thread.Interrupt`\n- `Response.End()` (calls Thread.Abort internally in ASP.NET Framework)\n- `Response.Redirect(url, true)` (the `true` parameter triggers Thread.Abort)\n- `SYSLIB0006` pragma suppressions\n\nRecord each usage location and classify the intent behind the abort.\n\n### Step 2: Classify each usage pattern\n\nCategorize every usage into one of the following patterns:\n\n| Pattern | Description | Modern replacement |\n|---------|-------------|--------------------|\n| **Cancellable work loop** | Thread running a loop that should stop on demand | `CancellationToken` checked in the loop |\n| **Timeout enforcement** | Aborting a thread that exceeds a time limit | `CancellationTokenSource.CancelAfter` or `Task.WhenAny` with a delay |\n| **Blocking call interruption** | Thread blocked on `Sleep`, `WaitOne`, or `Join` that needs to wake up | `WaitHandle.WaitAny` with `CancellationToken.WaitHandle`, or async alternatives |\n| **ASP.NET request termination** | `Response.End` or `Response.Redirect(url, true)` | Return from the action method; use `HttpContext.RequestAborted` |\n| **ThreadAbortException as control flow** | Catch blocks that inspect `ThreadAbortException` to decide cleanup actions | Catch `OperationCanceledException` instead, with explicit cleanup |\n| **Thread.ResetAbort to continue execution** | Catching the abort and calling `ResetAbort` to keep the thread alive | Check `CancellationToken.IsCancellationRequested` and decide whether to continue |\n| **Uncooperative code termination** | Killing a thread running code that cannot be modified to check for cancellation | Move the work to a separate process and use `Process.Kill` |\n\n**Critical:** The fundamental paradigm shift is from preemptive cancellation (the runtime forcibly injects an exception) to cooperative cancellation (the code must voluntarily check for and respond to cancellation requests). Every call site must be evaluated for whether the target code can be modified to cooperate.\n\n### Step 3: Apply the replacement for each pattern\n\n- **Cancellable work loop**: Add a `CancellationToken` parameter. Replace the loop condition or add `token.ThrowIfCancellationRequested()` at safe checkpoints. The caller creates a `CancellationTokenSource` and calls `Cancel()` instead of `Thread.Abort()`.\n- **Timeout enforcement**: Use `new CancellationTokenSource(TimeSpan.FromSeconds(n))` or `cts.CancelAfter(timeout)`. Pass the token to the work. For task-based code, use `Task.WhenAny(workTask, Task.Delay(timeout, cts.Token))` and cancel the source if the delay wins; cancelling also disposes the delay's internal timer.\n- **Blocking call interruption**: Replace `Thread.Sleep(ms)` with `Task.Delay(ms, token)` or `token.WaitHandle.WaitOne(ms)`. Replace `ManualResetEvent.WaitOne()` with `WaitHandle.WaitAny(new[] { event, token.WaitHandle })`.\n- **ASP.NET request termination**: Remove `Response.End()` entirely — just return from the method. Replace `Response.Redirect(url, true)` with `Response.Redirect(url)` (without the `true` endResponse parameter) or return a redirect result. In ASP.NET Core, use `HttpContext.RequestAborted` as the cancellation token for long-running request work.\n- **ThreadAbortException as control flow**: Replace `catch (ThreadAbortException)` with `catch (OperationCanceledException)`. Move cleanup logic to `finally` blocks or `CancellationToken.Register` callbacks. Do not catch `OperationCanceledException` and swallow it — let it propagate unless you have a specific recovery action.\n- **Thread.ResetAbort to continue execution**: Break up \"abortable\" units of work so that cancellation in a processing loop can continue to the next unit instead of relying on `ResetAbort` to prevent tearing down the thread. Check `token.IsCancellationRequested` after each unit and decide whether to continue. Create a new `CancellationTokenSource` (optionally linked to a parent token) for each new unit of work rather than trying to reset an existing one.\n- **Uncooperative code termination**: If the code cannot be modified to accept a `CancellationToken` (e.g., third-party library, native call), move the work to a child process. The host process communicates via stdin\u002Fstdout or IPC and calls `Process.Kill` if a timeout expires.\n\n### Step 4: Clean up removed APIs\n\nAfter migrating all patterns, remove or replace any remaining references:\n\n| Removed API | Replacement |\n|-------------|-------------|\n| `Thread.Abort()` | `CancellationTokenSource.Cancel()` |\n| `ThreadAbortException` catch blocks | `OperationCanceledException` catch blocks |\n| `Thread.ResetAbort()` | Check `token.IsCancellationRequested` and decide whether to continue |\n| `Thread.Interrupt()` | Signal via `CancellationToken` or set a `ManualResetEventSlim` (also obsolete: `SYSLIB0046` in .NET 9) |\n| `Response.End()` | Remove the call; return from the method |\n| `Response.Redirect(url, true)` | `Response.Redirect(url)` without endResponse, or return a redirect result |\n| `#pragma warning disable SYSLIB0006` | Remove after replacing the Thread.Abort call |\n\n### Step 5: Verify the migration\n\n1. Build the project targeting the new framework. Confirm zero `SYSLIB0006` warnings and no `Thread.Abort`-related compile errors.\n2. Search the codebase for any remaining references to `Thread.Abort`, `ThreadAbortException`, `Thread.ResetAbort`, or `Thread.Interrupt`.\n3. Run existing tests. If tests relied on `Thread.Abort` for cleanup or timeout, update them to use `CancellationToken`.\n4. For timeout scenarios, verify that work actually stops within a reasonable time after cancellation is requested.\n5. For blocking call scenarios, verify that blocked threads wake up promptly when the token is cancelled.\n\n## Validation\n\n- [ ] No references to `Thread.Abort` remain in the migrated code\n- [ ] No `ThreadAbortException` catch blocks remain\n- [ ] No `Thread.ResetAbort` calls remain\n- [ ] No `SYSLIB0006` pragma suppressions remain\n- [ ] Project builds cleanly against the target framework with no thread-abort-related warnings\n- [ ] All cancellable work accepts a `CancellationToken` parameter\n- [ ] Timeout scenarios use `CancellationTokenSource.CancelAfter` or equivalent\n- [ ] Blocking calls use `WaitHandle.WaitAny` with `token.WaitHandle` or async alternatives\n- [ ] Existing tests pass or have been updated for cooperative cancellation\n\n## Common Pitfalls\n\n| Pitfall | Solution |\n|---------|----------|\n| Adding `CancellationToken` parameter but never checking it in long-running code | Insert `token.ThrowIfCancellationRequested()` at regular checkpoints in loops and between expensive operations. Cancellation only works if the code cooperates. |\n| Not passing the token through the full call chain | Every async or long-running method in the chain must accept and forward the `CancellationToken`. If one method in the chain ignores it, cancellation stalls at that point. |\n| Expecting `CancellationToken` to interrupt blocking synchronous calls like `Thread.Sleep` or `socket.Receive` | These calls do not check the token. Replace `Thread.Sleep(ms)` with `token.WaitHandle.WaitOne(ms)`. Replace synchronous I\u002FO with async overloads that accept a `CancellationToken`. |\n| Catching `OperationCanceledException` and swallowing it | Let `OperationCanceledException` propagate to the caller. Only catch it at the top-level orchestration point where you decide what to do after cancellation (log, clean up, return a result). |\n| Not disposing `CancellationTokenSource` | `CancellationTokenSource` is `IDisposable`. Wrap it in a `using` statement or dispose it in a `finally` block. Leaking it causes timer and callback leaks. |\n| Assuming cancellation is immediate | Cooperative cancellation only takes effect at the next checkpoint. If work items are large or the code has long gaps between checks, cancellation may be delayed. Design checkpoint frequency based on acceptable latency. |\n| Using `Thread.Interrupt` as a substitute for `Thread.Abort` | `Thread.Interrupt` is also not recommended in modern .NET. It only works on threads in `WaitSleepJoin` state and throws `ThreadInterruptedException`, which is a different exception type. Replace with `CancellationToken` signaling. |\n| Removing `ThreadAbortException` catch blocks without migrating the cleanup logic | `ThreadAbortException` catch blocks often contained critical cleanup (releasing locks, rolling back transactions). Move this logic to `finally` blocks or `CancellationToken.Register` callbacks before removing the catch. |\n\n## More Info\n\n- [Thread.Abort breaking change in .NET 6+](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Fcompatibility\u002Fcore-libraries\u002F6.0\u002Fthread-abort) — why `Thread.Abort` throws `PlatformNotSupportedException`\n- [Cancellation in managed threads](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fstandard\u002Fthreading\u002Fcancellation-in-managed-threads) — the cooperative cancellation model with `CancellationToken`\n- [CancellationTokenSource class](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fapi\u002Fsystem.threading.cancellationtokensource) — API reference for creating and managing cancellation tokens\n- [SYSLIB0006 warning](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Ffundamentals\u002Fsyslib-diagnostics\u002Fsyslib0006) — `Thread.Abort` is obsolete\n- [SYSLIB0046 warning](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Ffundamentals\u002Fsyslib-diagnostics\u002Fsyslib0046) — `Thread.Interrupt` is obsolete (added in .NET 9)\n- [`Task.WaitAsync(CancellationToken)`](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fapi\u002Fsystem.threading.tasks.task.waitasync) — cancellable waiting for task-based code (.NET 6+)\n","# Thread.Abort Migration\n\nThis skill helps an agent migrate .NET Framework code that uses `Thread.Abort` to the cooperative cancellation model required by modern .NET (6+). `Thread.Abort` throws `PlatformNotSupportedException` in modern .NET — there is no way to forcibly terminate a managed thread. The skill identifies the usage pattern first, then applies the correct replacement strategy.\n\n## When to Use\n\n- Migrating a .NET Framework project to .NET 6+ that calls `Thread.Abort`\n- Replacing `ThreadAbortException` catch blocks that use control flow or cleanup logic\n- Removing `Thread.ResetAbort` calls that cancel pending aborts\n- Replacing `Thread.Interrupt` for waking blocked threads\n- Migrating ASP.NET code that uses `Response.End` or `Response.Redirect(url, true)`, which internally call `Thread.Abort`\n- Resolving `PlatformNotSupportedException` or `SYSLIB0006` warnings after a target framework change\n\n## When Not to Use\n\n- **The code only uses `Thread.Join`, `Thread.Sleep`, or `Thread.Start` without any abort, interrupt, or `ThreadAbortException` catch blocks.** These APIs work identically in modern .NET — no migration is needed. Stop here and tell the user no migration is required. If you suggest modernization (e.g., `Task.Run`, `Parallel.ForEach`), you **must** explicitly state these are optional improvements unrelated to Thread.Abort migration, and the existing code will compile and run correctly as-is on the target framework.\n- The project will remain on .NET Framework indefinitely\n- The Thread.Abort usage is inside a third-party library you do not control\n\n## Inputs\n\n| Input | Required | Description |\n|-------|----------|-------------|\n| Source project or solution | Yes | The .NET Framework project containing Thread.Abort usage |\n| Target framework | Yes | The modern .NET version to target (e.g., `net8.0`) |\n| Thread.Abort usage locations | Recommended | Files or classes that reference `Thread.Abort`, `ThreadAbortException`, `Thread.ResetAbort`, or `Thread.Interrupt` |\n\n## Workflow\n\n> **Commit strategy:** Commit after each pattern replacement so the migration is reviewable and bisectable. Group related call sites (e.g., all cancellable work loops) into one commit.\n\n### Step 1: Inventory all thread termination usage\n\nSearch the codebase for all thread-termination-related APIs:\n\n- `Thread.Abort` and `thread.Abort()` (instance calls)\n- `ThreadAbortException` in catch blocks\n- `Thread.ResetAbort`\n- `Thread.Interrupt`\n- `Response.End()` (calls Thread.Abort internally in ASP.NET Framework)\n- `Response.Redirect(url, true)` (the `true` parameter triggers Thread.Abort)\n- `SYSLIB0006` pragma suppressions\n\nRecord each usage location and classify the intent behind the abort.\n\n### Step 2: Classify each usage pattern\n\nCategorize every usage into one of the following patterns:\n\n| Pattern | Description | Modern replacement |\n|---------|-------------|--------------------|\n| **Cancellable work loop** | Thread running a loop that should stop on demand | `CancellationToken` checked in the loop |\n| **Timeout enforcement** | Aborting a thread that exceeds a time limit | `CancellationTokenSource.CancelAfter` or `Task.WhenAny` with a delay |\n| **Blocking call interruption** | Thread blocked on `Sleep`, `WaitOne`, or `Join` that needs to wake up | `WaitHandle.WaitAny` with `CancellationToken.WaitHandle`, or async alternatives |\n| **ASP.NET request termination** | `Response.End` or `Response.Redirect(url, true)` | Return from the action method; use `HttpContext.RequestAborted` |\n| **ThreadAbortException as control flow** | Catch blocks that inspect `ThreadAbortException` to decide cleanup actions | Catch `OperationCanceledException` instead, with explicit cleanup |\n| **Thread.ResetAbort to continue execution** | Catching the abort and calling `ResetAbort` to keep the thread alive | Check `CancellationToken.IsCancellationRequested` and decide whether to continue |\n| **Uncooperative code termination** | Killing a thread running code that cannot be modified to check for cancellation | Move the work to a separate process and use `Process.Kill` |\n\n**Critical:** The fundamental paradigm shift is from preemptive cancellation (the runtime forcibly injects an exception) to cooperative cancellation (the code must voluntarily check for and respond to cancellation requests). Every call site must be evaluated for whether the target code can be modified to cooperate.\n\n### Step 3: Apply the replacement for each pattern\n\n- **Cancellable work loop**: Add a `CancellationToken` parameter. Replace the loop condition or add `token.ThrowIfCancellationRequested()` at safe checkpoints. The caller creates a `CancellationTokenSource` and calls `Cancel()` instead of `Thread.Abort()`.\n- **Timeout enforcement**: Use `new CancellationTokenSource(TimeSpan.FromSeconds(n))` or `cts.CancelAfter(timeout)`. Pass the token to the work. For task-based code, use `Task.WhenAny(workTask, Task.Delay(timeout, cts.Token))` and cancel the source if the delay wins; cancelling also disposes the delay's internal timer.\n- **Blocking call interruption**: Replace `Thread.Sleep(ms)` with `Task.Delay(ms, token)` or `token.WaitHandle.WaitOne(ms)`. Replace `ManualResetEvent.WaitOne()` with `WaitHandle.WaitAny(new[] { event, token.WaitHandle })`.\n- **ASP.NET request termination**: Remove `Response.End()` entirely — just return from the method. Replace `Response.Redirect(url, true)` with `Response.Redirect(url)` (without the `true` endResponse parameter) or return a redirect result. In ASP.NET Core, use `HttpContext.RequestAborted` as the cancellation token for long-running request work.\n- **ThreadAbortException as control flow**: Replace `catch (ThreadAbortException)` with `catch (OperationCanceledException)`. Move cleanup logic to `finally` blocks or `CancellationToken.Register` callbacks. Do not catch `OperationCanceledException` and swallow it — let it propagate unless you have a specific recovery action.\n- **Thread.ResetAbort to continue execution**: Break up \"abortable\" units of work so that cancellation in a processing loop can continue to the next unit instead of relying on `ResetAbort` to prevent tearing down the thread. Check `token.IsCancellationRequested` after each unit and decide whether to continue. Create a new `CancellationTokenSource` (optionally linked to a parent token) for each new unit of work rather than trying to reset an existing one.\n- **Uncooperative code termination**: If the code cannot be modified to accept a `CancellationToken` (e.g., third-party library, native call), move the work to a child process. The host process communicates via stdin\u002Fstdout or IPC and calls `Process.Kill` if a timeout expires.\n\n### Step 4: Clean up removed APIs\n\nAfter migrating all patterns, remove or replace any remaining references:\n\n| Removed API | Replacement |\n|-------------|-------------|\n| `Thread.Abort()` | `CancellationTokenSource.Cancel()` |\n| `ThreadAbortException` catch blocks | `OperationCanceledException` catch blocks |\n| `Thread.ResetAbort()` | Check `token.IsCancellationRequested` and decide whether to continue |\n| `Thread.Interrupt()` | Signal via `CancellationToken` or set a `ManualResetEventSlim` (also obsolete: `SYSLIB0046` in .NET 9) |\n| `Response.End()` | Remove the call; return from the method |\n| `Response.Redirect(url, true)` | `Response.Redirect(url)` without endResponse, or return a redirect result |\n| `#pragma warning disable SYSLIB0006` | Remove after replacing the Thread.Abort call |\n\n### Step 5: Verify the migration\n\n1. Build the project targeting the new framework. Confirm zero `SYSLIB0006` warnings and no `Thread.Abort`-related compile errors.\n2. Search the codebase for any remaining references to `Thread.Abort`, `ThreadAbortException`, `Thread.ResetAbort`, or `Thread.Interrupt`.\n3. Run existing tests. If tests relied on `Thread.Abort` for cleanup or timeout, update them to use `CancellationToken`.\n4. For timeout scenarios, verify that work actually stops within a reasonable time after cancellation is requested.\n5. For blocking call scenarios, verify that blocked threads wake up promptly when the token is cancelled.\n\n## Validation\n\n- [ ] No references to `Thread.Abort` remain in the migrated code\n- [ ] No `ThreadAbortException` catch blocks remain\n- [ ] No `Thread.ResetAbort` calls remain\n- [ ] No `SYSLIB0006` pragma suppressions remain\n- [ ] Project builds cleanly against the target framework with no thread-abort-related warnings\n- [ ] All cancellable work accepts a `CancellationToken` parameter\n- [ ] Timeout scenarios use `CancellationTokenSource.CancelAfter` or equivalent\n- [ ] Blocking calls use `WaitHandle.WaitAny` with `token.WaitHandle` or async alternatives\n- [ ] Existing tests pass or have been updated for cooperative cancellation\n\n## Common Pitfalls\n\n| Pitfall | Solution |\n|---------|----------|\n| Adding `CancellationToken` parameter but never checking it in long-running code | Insert `token.ThrowIfCancellationRequested()` at regular checkpoints in loops and between expensive operations. Cancellation only works if the code cooperates. |\n| Not passing the token through the full call chain | Every async or long-running method in the chain must accept and forward the `CancellationToken`. If one method in the chain ignores it, cancellation stalls at that point. |\n| Expecting `CancellationToken` to interrupt blocking synchronous calls like `Thread.Sleep` or `socket.Receive` | These calls do not check the token. Replace `Thread.Sleep(ms)` with `token.WaitHandle.WaitOne(ms)`. Replace synchronous I\u002FO with async overloads that accept a `CancellationToken`. |\n| Catching `OperationCanceledException` and swallowing it | Let `OperationCanceledException` propagate to the caller. Only catch it at the top-level orchestration point where you decide what to do after cancellation (log, clean up, return a result). |\n| Not disposing `CancellationTokenSource` | `CancellationTokenSource` is `IDisposable`. Wrap it in a `using` statement or dispose it in a `finally` block. Leaking it causes timer and callback leaks. |\n| Assuming cancellation is immediate | Cooperative cancellation only takes effect at the next checkpoint. If work items are large or the code has long gaps between checks, cancellation may be delayed. Design checkpoint frequency based on acceptable latency. |\n| Using `Thread.Interrupt` as a substitute for `Thread.Abort` | `Thread.Interrupt` is also not recommended in modern .NET. It only works on threads in `WaitSleepJoin` state and throws `ThreadInterruptedException`, which is a different exception type. Replace with `CancellationToken` signaling. |\n| Removing `ThreadAbortException` catch blocks without migrating the cleanup logic | `ThreadAbortException` catch blocks often contained critical cleanup (releasing locks, rolling back transactions). Move this logic to `finally` blocks or `CancellationToken.Register` callbacks before removing the catch. |\n\n## More Info\n\n- [Thread.Abort breaking change in .NET 6+](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fcore\u002Fcompatibility\u002Fcore-libraries\u002F6.0\u002Fthread-abort) — why `Thread.Abort` throws `PlatformNotSupportedException`\n- [Cancellation in managed threads](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fstandard\u002Fthreading\u002Fcancellation-in-managed-threads) — the cooperative cancellation model with `CancellationToken`\n- [CancellationTokenSource class](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fapi\u002Fsystem.threading.cancellationtokensource) — API reference for creating and managing cancellation tokens\n- [SYSLIB0006 warning](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Ffundamentals\u002Fsyslib-diagnostics\u002Fsyslib0006) — `Thread.Abort` is obsolete\n- [SYSLIB0046 warning](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Ffundamentals\u002Fsyslib-diagnostics\u002Fsyslib0046) — `Thread.Interrupt` is obsolete (added in .NET 9)\n- [`Task.WaitAsync(CancellationToken)`](https:\u002F\u002Flearn.microsoft.com\u002Fdotnet\u002Fapi\u002Fsystem.threading.tasks.task.waitasync) — cancellable waiting for task-based code (.NET 6+)\n",{"name":5,"license":15,"description":48},"Guides migration of .NET Framework Thread.Abort usage to cooperative cancellation in modern .NET. USE FOR: modernizing code that calls Thread.Abort, catching ThreadAbortException, replacing Thread.ResetAbort, replacing Thread.Interrupt for thread termination, resolving PlatformNotSupportedException or SYSLIB0006 after retargeting to .NET 6+, migrating ASP.NET Response.End or Response.Redirect(url, true) which internally call Thread.Abort. DO NOT USE FOR: code that only uses Thread.Join, Thread.Sleep, or Thread.Start without any abort, interrupt, or ThreadAbortException usage — these APIs work identically in modern .NET and need no migration. Also not for projects staying on .NET Framework, or Thread.Abort usage inside third-party libraries you do not control.\n","main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","external-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-upgrade\u002Fskills\u002Fthread-abort-migration",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-12 19:59:36",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add managedcode\u002Fdotnet-skills --skill thread-abort-migration",{"tool":65,"command":66},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill thread-abort-migration",{"tool":68,"command":69},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill thread-abort-migration","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet-upgrade\u002Fskills\u002Fthread-abort-migration\u002FSKILL.md",true,[73,79,83,87,93],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"index.json","REFERENCE","参考文档",1077,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvuln-remediation-bucket\u002Findex.json",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fapi-reference.md",2595,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvuln-remediation-bucket\u002Freferences\u002Fapi-reference.md",{"path":84,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Findex.json",84,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvuln-remediation-bucket\u002Freferences\u002Findex.json",{"path":88,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":91,"sourceHtmlUrl":92},"scripts\u002Fagent.py","SCRIPT","脚本",7661,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvuln-remediation-bucket\u002Fscripts\u002Fagent.py",{"path":94,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":85,"sourceHtmlUrl":95},"scripts\u002Findex.json","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvuln-remediation-bucket\u002Fscripts\u002Findex.json",[97,133,157,188,198,224],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":113,"publishedAt":43},"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",[103,108],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[114,115,116,117,42,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132],"xtwitter scraper","browser automation","workflows","run","browser","search","repository","api","Media","api client","access","edit","unrelated","webhooks","files","social","commands","modeling","webhook",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":145,"publishedAt":43},"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",[139,142],{"categoryNo":140,"categoryName":141,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":143,"categoryName":144,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000036","内容创作者",[135,146,147,116,148,117,120,149,150,151,125,152,126,128,35,153,154,155,130,156],"writing","performance","tasks","data","parsing","parser","context","writer","options","project","high-performance",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":43},"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",[],[164,165,166,167,168,169,170,171,172,173,174,175,37,176,177,178,179,180,181,182,183,184,185,186,187],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","node","syntax","guide","language","three","compute","post","processing","with","renderer","for","materials","wgsl","effects","when",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":43},"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",[],[190,37,128,195,196,183,197],"semantic","razor","inspection",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":43},"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",[],[205,206,207,208,146,209,210,211,212,213,214,37,36,215,216,217,35,218,219,220,221,183,222,223,187],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":225,"name":226,"nameZh":6,"description":227,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":228,"categories":229,"keywords":232,"publishedAt":43},"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",[230,231],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},[121,233,234,235,117,40,171,205,37,216,217,35,236,237,238,25,221,183,239],"process","process api net11","diagnostics","basic","processes","output","new"]