.NET 11 repareert eindelijk de Proces-API

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

Elke .NET-ontwikkelaar die ooit een proces moest starten en de uitvoer ervan moest vastleggen, heeft een variatie op dezelfde gevaarlijke boilerplate geschreven: async lezen van stdout, async lezen van stderr, WaitForExitAsync, vergeet niet beide streams te leegmaken of je krijgt een deadlock. Het is een bekende val die al jaren bestaat.

.NET 11 lost dit eindelijk goed op.

RunAndCaptureTextAsync

De belangrijkste toevoeging: één enkele statische methode die een proces start, stdout en stderr vastlegt, en wacht op beëindiging zonder deadlock.

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

Één aanroep. Geen handmatig leegmaken van streams. Geen zorgvuldig geplaatste WaitForExit. Als u gewoon iets wilt uitvoeren en de uitvoer wilt ontvangen, is dit de API die u wilt.

Er is ook Process.RunAsync voor het geval u wilt wachten op beëindiging zonder de uitvoer te vastleggen.

KillOnParentExit

Een veelvoorkomend probleem met gestarte processen: als het bovenliggende proces crasht of wordt beëindigd, blijven de onderliggende processen als wezen draaien. KillOnParentExit stelt u in staat om bij het starten van het proces te declareren dat het onderliggende proces beëindigd moet worden wanneer het bovenliggende proces wordt beëindigd.

Dit is een functie die op platformspecifieke manieren bestond (job objects op Windows, prctl op Linux) maar p/invoke of externe bibliotheken vereiste voor gebruik vanuit .NET. Nu is het een eersteklas eigenschap op ProcessStartInfo.

SafeProcessHandle-gebaseerde API’s

Het nieuwe lichtgewicht API-oppervlak is gebouwd rond SafeProcessHandle in plaats van de volledige klasse Process. De volledige klasse Process draagt veel toestand met zich mee en is moeilijk te trimmen — het SafeProcessHandle-pad is trimmer-vriendelijker voor toepassingen die de uitvoergrootte moeten minimaliseren (WASM, native AOT).

Volledige Controle over Handle-erfenis

De update voegt ook gedetailleerde controle toe over welke handles een onderliggend proces erft en hoe standaard handles worden omgeleid. Voorheen kon u stdin/stdout/stderr omleiden, maar kon u niet precies specificeren welke handles op OS-niveau geërfd worden. De nieuwe API’s stellen die controle bloot.

Waarom Dit Belangrijk Is

De klasse Process wordt gebruikt in tooling, buildsystemen, testrunners en elke toepassing die andere uitvoerbare bestanden aanroept. Het oude API-oppervlak dateerde uit het .NET Framework-tijdperk en toonde zijn leeftijd. Dit is geen afbrekende wijziging — de oude API’s werken nog steeds — maar nieuwe code moet de voorkeur geven aan het nieuwe oppervlak.

Voor getrimde toepassingen of AOT-compilatiescenario’s is het SafeProcessHandle-pad bijzonder welkom. De oude klasse Process bracht veel reflection-zwaar code mee dat het trimmen bemoeilijkte.

Originele post: Process API Improvements in .NET 11

Hoe Copilot Studio Migreerde naar .NET 10 WebAssembly en 20% Sneller Werd

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

Het Copilot Studio-team deed iets waar alle Blazor WASM-ontwikkelaars nieuwsgierig naar waren: ze upgradeden daadwerkelijk een productieapplicatie van .NET 8 naar .NET 10 en maten de resultaten. De post deelt specifieke cijfers, wat zeldzaam en oprecht nuttig is.

De Upgrade Was Saai (Dat is een Goede Zaak)

Target framework bijwerken, pakketreferenties vernieuwen, breaking changes oplossen. Dat is alles. De .NET 10-build draait nu in productie. De migratie zelf was niet het interessante deel — de wijzigingen in .NET 10 zijn dat.

Automatische Asset Fingerprinting

Vroeger betekende het distribueren van een WASM-app het schrijven van aangepaste scripts om gepubliceerde assets te hernoemen met SHA256-hashes voor cache-busting. Copilot Studio had een PowerShell-script dat precies dit deed — bestanden hernoemen, integrity-attributen injecteren in de JavaScript-loader, alles handmatig beheren.

In .NET 10 is dit allemaal ingebouwd. Gepubliceerde assets krijgen automatisch een fingerprint, worden direct geïmporteerd vanuit dotnet.js en worden gevalideerd op integriteit zonder handmatige tussenkomst. Het team verwijderde het hernoem-script.

Kleine verandering in scope, aanzienlijke vermindering van complexiteit.

WasmStripILAfterAOT Is Nu Standaard Ingeschakeld

In .NET 8 was het verwijderen van IL uit AOT-gecompileerde assemblies opt-in. In .NET 10 is het de standaard. Na AOT-compilatie wordt de oorspronkelijke IL-bytecode verwijderd uit de uitvoer — het is niet nodig tijdens runtime, en het bewaren ervan blies de pakketgrootte op zonder reden.

Copilot Studio gebruikt een specifieke optimalisatie: het levert zowel een JIT-engine (snelle opstart) als een AOT-engine (maximale steady-state prestaties), laadt beide parallel en geeft over van JIT naar AOT zodra het klaar is. Het dedupliceert ook bestanden die identiek zijn tussen de twee engines.

Het nieuwe IL-stripping gedrag betekent dat AOT-assemblies niet meer bit-voor-bit overeenkomen met hun JIT-tegenhangers, dus worden er minder bestanden gededupliceerd:

.NET 8: 59 gedeelde bestanden
.NET 10: 22 gedeelde bestanden

Nettoresultaat: pakketgrootte ongeveer 15% groter voor de AOT-engine. De AOT-download is ~6% langzamer op snel LAN, ~17% langzamer op 4G. Maar dit alles gebeurt op de achtergrond nadat de app al interactief is.

De Prestatiecijfers

Dit is het deel dat telt:

~20% sneller bij de eerste aanroep (koud pad)
~5% sneller bij volgende aanroepen (warm pad)

De verbeteringen zijn het meest zichtbaar in “grote bots” — grote, complexe agents waar AOT-gecompileerde code domineert. Voor eenvoudigere workflows is de winst kleiner.

Als U Nog op .NET 8 Bent

Het migratieverhaal is oprecht eenvoudig: update <TargetFramework>, vernieuw pakketreferenties, verwijder aangepaste fingerprinting-scripts, en u profiteert automatisch van WasmStripILAfterAOT. Als u AOT compileert, verwacht dan vergelijkbare prestatiewinsten.

Een opmerking uit de post: als u de .NET WASM-runtime laadt binnen een WebWorker, stel dan dotnetSidecar = true in bij het initialiseren.

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

Performance | The .NET Blog