domains / families / software-engineering / thread-abort-migration

thread-abort-migration

separate

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.

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

Skill page

Source