.NET 11 Finally Fixes the Process API

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

Every .NET developer who has ever needed to spawn a process and capture its output has written some variation of the same dangerous boilerplate: async read from stdout, async read from stderr, WaitForExitAsync, don’t forget to drain both streams or you’ll deadlock. It’s a well-known trap that’s been there for years.

.NET 11 finally fixes this properly.

RunAndCaptureTextAsync

The headline addition: a single static method that starts a process, captures stdout and stderr, and waits for exit without deadlocking.

var result = await Process.RunAndCaptureTextAsync("dotnet", "--version");
Console.WriteLine(result.StandardOutput);

One call. No manual stream draining. No carefully positioned WaitForExit. If you just need to run something and get its output, this is the API you want.

There’s also Process.RunAsync for the case where you want to wait for exit without capturing output.

KillOnParentExit

A common problem with spawned processes: if the parent crashes or is killed, child processes keep running as orphans. KillOnParentExit lets you declare at process start time that the child process should be terminated when the parent process exits.

This is a feature that’s existed in platform-specific ways (job objects on Windows, prctl on Linux) but required p/invoke or third-party libraries to use from .NET. Now it’s a first-class property on ProcessStartInfo.

SafeProcessHandle-Based APIs

The new lightweight API surface is built around SafeProcessHandle rather than the full Process class. The full Process class carries a lot of state and is difficult to trim — the SafeProcessHandle path is more trimmer-friendly for applications that need to minimize output size (WASM, native AOT).

Full Control Over Handle Inheritance

The update also adds fine-grained control over which handles a child process inherits and how standard handles are redirected. Previously you could redirect stdin/stdout/stderr but couldn’t specify exactly which handles to inherit at the OS level. The new APIs expose that control.

Why This Matters

The Process class is used in tooling, build systems, test runners, and any application that shells out to other executables. The old API surface dated back to .NET Framework and was showing its age. This isn’t a breaking change — the old APIs still work — but new code should prefer the new surface.

For trimmed applications or AOT compilation scenarios, the SafeProcessHandle path is particularly welcome. The old Process class brought in a lot of reflection-heavy code that complicated trimming.

Original post: Process API Improvements in .NET 11

How Copilot Studio Migrated to .NET 10 WebAssembly and Got 20% Faster

Emiliano Montesdeoca — Sat, 23 May 2026 00:00:00 +0000

The Copilot Studio team did something every Blazor WASM developer has been curious about: they actually upgraded a production application from .NET 8 to .NET 10 and measured the results. The post shares specific numbers, which is rare and genuinely useful.

The Upgrade Was Boring (That’s a Good Thing)

Updating target framework, refreshing package references, fixing any breaking changes. That’s it. The .NET 10 build is now running in production. The migration itself wasn’t the interesting part — the changes in .NET 10 are.

Automatic Asset Fingerprinting

Previously, shipping a WASM app meant writing custom scripts to rename published assets with SHA256 hashes for cache-busting. Copilot Studio had a PowerShell script doing exactly this — rename files, inject integrity attributes into the JavaScript loader, manage the whole thing manually.

In .NET 10, all of that is built in. Published assets are automatically fingerprinted, imported directly from dotnet.js, and integrity-validated without manual intervention. The team deleted the renaming script.

Small change in scope, significant reduction in complexity.

WasmStripILAfterAOT Is Now On by Default

In .NET 8, stripping IL from AOT-compiled assemblies was opt-in. In .NET 10 it’s the default. After AOT compilation, the original IL bytecode is removed from the output — it isn’t needed at runtime, and keeping it was inflating package size for no reason.

Copilot Studio uses a specific optimization: it ships both a JIT engine (fast startup) and an AOT engine (maximum steady-state performance), loading both in parallel and handing off from JIT to AOT once it’s ready. It also deduplicates files that are identical between the two engines.

The new IL stripping behavior means AOT assemblies no longer match their JIT counterparts bit-for-bit, so fewer files are deduplicated:

.NET 8: 59 shared files
.NET 10: 22 shared files

Net result: roughly 15% larger package size for the AOT engine. The AOT download is ~6% slower on fast LAN, ~17% slower on 4G. But it all happens in the background after the app is already interactive.

The Performance Numbers

This is the part that matters:

~20% faster on the first call (cold path)
~5% faster on subsequent calls (warm path)

The improvements are most visible in “big bots” — large, complex agents where AOT-compiled code dominates. For simpler workflows the gain is smaller.

If You’re Still on .NET 8

The migration story is genuinely simple: update <TargetFramework>, refresh package references, remove any custom fingerprinting scripts, and you’ll automatically benefit from WasmStripILAfterAOT. If you’re AOT-compiling, expect similar performance gains.

One note from the post: if you load the .NET WASM runtime inside a WebWorker, set dotnetSidecar = true when initializing.

Original post: Copilot Studio gets faster with .NET 10 on WebAssembly

Performance | The .NET Blog