.NET 11 behebt endlich die Prozess-API

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

Jeder .NET-Entwickler, der jemals einen Prozess starten und seine Ausgabe erfassen musste, hat irgendeine Variante desselben gefährlichen Boilerplate-Codes geschrieben: async-Lesen von stdout, async-Lesen von stderr, WaitForExitAsync — und bloß nicht vergessen, beide Streams zu leeren, sonst gibt es einen Deadlock. Es ist eine bekannte Falle, die seit Jahren besteht.

.NET 11 behebt das endlich ordentlich.

RunAndCaptureTextAsync

Die wichtigste Ergänzung: eine einzelne statische Methode, die einen Prozess startet, stdout und stderr erfasst und auf das Beenden wartet — ohne Deadlock.

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

Ein einziger Aufruf. Kein manuelles Leeren der Streams. Kein sorgfältig positioniertes WaitForExit. Wenn Sie einfach etwas ausführen und dessen Ausgabe erhalten müssen, ist das die API, die Sie wollen.

Es gibt auch Process.RunAsync für den Fall, dass Sie auf das Beenden warten möchten, ohne die Ausgabe zu erfassen.

KillOnParentExit

Ein häufiges Problem mit gestarteten Prozessen: Wenn der übergeordnete Prozess abstürzt oder beendet wird, laufen die untergeordneten Prozesse als Waisen weiter. KillOnParentExit ermöglicht es Ihnen, beim Start des Prozesses anzugeben, dass der untergeordnete Prozess beendet werden soll, wenn der übergeordnete Prozess beendet wird.

Diese Funktion existierte auf plattformspezifische Weise (Job Objects unter Windows, prctl unter Linux), erforderte aber p/invoke oder Drittanbieter-Bibliotheken zur Verwendung aus .NET. Jetzt ist es eine erstklassige Eigenschaft von ProcessStartInfo.

SafeProcessHandle-basierte APIs

Die neue leichtgewichtige API-Oberfläche ist um SafeProcessHandle anstelle der vollständigen Process-Klasse aufgebaut. Die vollständige Process-Klasse trägt viel Zustand und ist schwer zu trimmen — der SafeProcessHandle-Pfad ist trimmer-freundlicher für Anwendungen, die die Ausgabegröße minimieren müssen (WASM, native AOT).

Vollständige Kontrolle über Handle-Vererbung

Das Update fügt auch eine feinkörnige Kontrolle darüber hinzu, welche Handles ein untergeordneter Prozess erbt und wie Standard-Handles umgeleitet werden. Bisher konnte man stdin/stdout/stderr umleiten, aber nicht genau festlegen, welche Handles auf Betriebssystemebene vererbt werden sollen. Die neuen APIs machen diese Kontrolle zugänglich.

Warum Das Wichtig Ist

Die Process-Klasse wird in Tooling, Build-Systemen, Test-Runnern und jeder Anwendung verwendet, die andere Executables aufruft. Die alte API-Oberfläche stammte noch aus .NET Framework und zeigte ihr Alter. Das ist keine Breaking Change — die alten APIs funktionieren weiterhin — aber neuer Code sollte die neue Oberfläche bevorzugen.

Für getrimte Anwendungen oder AOT-Kompilierungsszenarien ist der SafeProcessHandle-Pfad besonders willkommen. Die alte Process-Klasse brachte viel reflektionslastigen Code mit, der das Trimmen erschwerte.

Original-Post: Process API Improvements in .NET 11

Wie Copilot Studio auf .NET 10 WebAssembly Migrierte und 20% Schneller Wurde

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

Das Copilot Studio-Team hat etwas getan, worüber alle Blazor WASM-Entwickler neugierig waren: Sie haben tatsächlich eine Produktionsanwendung von .NET 8 auf .NET 10 aktualisiert und die Ergebnisse gemessen. Der Beitrag teilt spezifische Zahlen, was selten und wirklich nützlich ist.

Das Upgrade War Langweilig (Das ist eine Gute Sache)

Ziel-Framework aktualisieren, Paketreferenzen auffrischen, Breaking Changes beheben. Das ist alles. Der .NET 10-Build läuft jetzt in der Produktion. Die Migration selbst war nicht der interessante Teil — die Änderungen in .NET 10 sind es.

Automatisches Asset-Fingerprinting

Früher bedeutete das Bereitstellen einer WASM-App das Schreiben benutzerdefinierter Skripte zum Umbenennen veröffentlichter Assets mit SHA256-Hashes für Cache-Busting. Copilot Studio hatte ein PowerShell-Skript, das genau das tat — Dateien umbenennen, integrity-Attribute in den JavaScript-Loader injizieren, alles manuell verwalten.

In .NET 10 ist all das integriert. Veröffentlichte Assets werden automatisch mit Fingerprint versehen, direkt aus dotnet.js importiert und ohne manuelle Eingriffe mit Integrität validiert. Das Team löschte das Umbenennungsskript.

Kleine Änderung im Umfang, deutliche Reduzierung der Komplexität.

WasmStripILAfterAOT Ist Jetzt Standardmäßig Aktiviert

In .NET 8 war das Entfernen von IL aus AOT-kompilierten Assemblys opt-in. In .NET 10 ist es der Standard. Nach der AOT-Kompilierung wird der ursprüngliche IL-Bytecode aus der Ausgabe entfernt — er wird zur Laufzeit nicht benötigt, und ihn zu behalten blähte die Paketgröße grundlos auf.

Copilot Studio verwendet eine spezifische Optimierung: Es liefert sowohl eine JIT-Engine (schneller Start) als auch eine AOT-Engine (maximale Steady-State-Leistung), lädt beide parallel und übergibt von JIT an AOT, sobald sie bereit ist. Es dedupliziert auch Dateien, die zwischen den beiden Engines identisch sind.

Das neue IL-Stripping-Verhalten bedeutet, dass AOT-Assemblys nicht mehr Bit-für-Bit mit ihren JIT-Gegenstücken übereinstimmen, sodass weniger Dateien dedupliziert werden:

.NET 8: 59 gemeinsame Dateien
.NET 10: 22 gemeinsame Dateien

Nettoergebnis: etwa 15% größere Paketgröße für die AOT-Engine. Der AOT-Download ist ~6% langsamer auf schnellem LAN, ~17% langsamer auf 4G. Aber das alles passiert im Hintergrund, nachdem die App bereits interaktiv ist.

Die Leistungszahlen

Das ist der wichtige Teil:

~20% schneller beim ersten Aufruf (kalter Pfad)
~5% schneller bei nachfolgenden Aufrufen (warmer Pfad)

Die Verbesserungen sind am sichtbarsten bei “großen Bots” — großen, komplexen Agenten, bei denen AOT-kompilierter Code dominiert. Für einfachere Workflows ist der Gewinn kleiner.

Wenn Sie Noch auf .NET 8 Sind

Die Migrationsgeschichte ist wirklich einfach: Aktualisieren Sie <TargetFramework>, aktualisieren Sie Paketreferenzen, entfernen Sie benutzerdefinierte Fingerprinting-Skripte, und Sie profitieren automatisch von WasmStripILAfterAOT. Wenn Sie AOT kompilieren, erwarten Sie ähnliche Leistungsgewinne.

Ein Hinweis aus dem Beitrag: Wenn Sie die .NET WASM-Laufzeitumgebung in einem WebWorker laden, setzen Sie dotnetSidecar = true bei der Initialisierung.

Originalbeitrag: Copilot Studio gets faster with .NET 10 on WebAssembly

Performance | The .NET Blog