/thread-abort-migration

name: thread-abort-migration
description: >
  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.
license: MIT

Thread.Abort Migration

This 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.

When to Use

• Migrating a .NET Framework project to .NET 6+ that calls `Thread.Abort`
• Replacing `ThreadAbortException` catch blocks that use control flow or cleanup logic
• Removing `Thread.ResetAbort` calls that cancel pending aborts
• Replacing `Thread.Interrupt` for waking blocked threads
• Migrating ASP.NET code that uses `Response.End` or `Response.Redirect(url, true)`, which internally call `Thread.Abort`
• Resolving `PlatformNotSupportedException` or `SYSLIB0006` warnings after a target framework change

When Not to Use

• **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.
• The project will remain on .NET Framework indefinitely
• The Thread.Abort usage is inside a third-party library you do not control

Inputs

| Input | Required | Description | |-------|----------|-------------| | Source project or solution | Yes | The .NET Framework project containing Thread.Abort usage | | Target framework | Yes | The modern .NET version to target (e.g., `net8.0`) | | Thread.Abort usage locations | Recommended | Files or classes that reference `Thread.Abort`, `ThreadAbortException`, `Thread.ResetAbort`, or `Thread.Interrupt` |

Workflow

> **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.

Step 1: Inventory all thread termination usage

Search the codebase for all thread-termination-related APIs:

• `Thread.Abort` and `thread.Abort()` (instance calls)
• `ThreadAbortException` in catch blocks
• `Thread.ResetAbort`
• `Thread.Interrupt`
• `Response.End()` (calls Thread.Abort internally in ASP.NET Framework)
• `Response.Redirect(url, true)` (the `true` parameter triggers Thread.Abort)
• `SYSLIB0006` pragma suppressions

Record each usage location and classify the intent behind the abort.

Step 2: Classify each usage pattern

Categorize every usage into one of the following patterns:

| Pattern | Description | Modern replacement | |---------|-------------|--------------------| | **Cancellable work loop** | Thread running a loop that should stop on demand | `CancellationToken` checked in the loop | | **Timeout enforcement** | Aborting a thread that exceeds a time limit | `CancellationTokenSource.CancelAfter` or `Task.WhenAny` with a delay | | **Blocking call interruption** | Thread blocked on `Sleep`, `WaitOne`, or `Join` that needs to wake up | `WaitHandle.WaitAny` with `CancellationToken.WaitHandle`, or async alternatives | | **ASP.NET request termination** | `Response.End` or `Response.Redirect(url, true)` | Return from the action method; use `HttpContext.RequestAborted` | | **ThreadAbortException as control flow** | Catch blocks that inspect `ThreadAbortException` to decide cleanup actions | Catch `OperationCanceledException` instead, with explicit cleanup | | **Thread.ResetAbort to continue execution** | Catching the abort and calling `ResetAbort` to keep the thread alive | Check `CancellationToken.IsCancellationRequested` and decide whether to continue | | **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` |

**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.

Step 3: Apply the replacement for each pattern

• **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()`.
• **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.
• **Blocking call interruption**: Replace `Thread.Sleep(ms)` with `Task.Delay(ms, token)` or