.NET 11 finalment arregla l'API de Processos

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

Tot desenvolupador .NET que alguna vegada ha hagut de llançar un procés i capturar la seva sortida ha escrit alguna variació del mateix codi repetitiu perillós: lectura async de stdout, lectura async de stderr, WaitForExitAsync, sense oblidar buidar tots dos streams o causaràs un bloqueig mort. És una trampa ben coneguda que existeix des de fa anys.

.NET 11 finalment ho arregla correctament.

RunAndCaptureTextAsync

L’addició principal: un únic mètode estàtic que inicia un procés, captura stdout i stderr, i espera la sortida sense bloqueig mort.

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

Una sola crida. Sense buidatge manual de streams. Sense un WaitForExit col·locat acuradament. Si simplement necessiteu executar alguna cosa i obtenir la seva sortida, aquesta és l’API que voleu.

Hi ha també Process.RunAsync per al cas en què voleu esperar la sortida sense capturar el resultat.

KillOnParentExit

Un problema comú amb els processos llançats: si el pare falla o és acabat, els processos fill continuen executant-se com a orfes. KillOnParentExit us permet declarar en el moment d’iniciar el procés que el procés fill ha d’acabar quan el procés pare surti.

Aquesta és una funcionalitat que existia de maneres específiques per plataforma (job objects a Windows, prctl a Linux) però requeria p/invoke o biblioteques de tercers per ser usada des de .NET. Ara és una propietat de primera classe a ProcessStartInfo.

APIs Basades en SafeProcessHandle

La nova superfície d’API lleugera es construeix al voltant de SafeProcessHandle en lloc de la classe Process completa. La classe Process completa porta molt d’estat i és difícil de retallar — el camí SafeProcessHandle és més amigable amb el trimmer per a aplicacions que necessiten minimitzar la mida de sortida (WASM, AOT natiu).

Control Total Sobre l’Herència d’Identificadors

L’actualització també afegeix control detallat sobre quins identificadors hereda un procés fill i com es redireccionen els identificadors estàndard. Anteriorment podíeu redirigir stdin/stdout/stderr però no podíeu especificar exactament quins identificadors heretar a nivell de SO. Les noves APIs exposen aquest control.

Per Què És Important

La classe Process s’usa en eines, sistemes de compilació, executors de proves i qualsevol aplicació que invoca altres executables. L’antiga superfície d’API datava de .NET Framework i estava mostrant la seva edat. No és un canvi que trenca la compatibilitat — les APIs antigues segueixen funcionant — però el nou codi hauria de preferir la nova superfície.

Per a aplicacions retallades o escenaris de compilació AOT, el camí SafeProcessHandle és especialment benvingut. L’antiga classe Process portava molt codi pesat en reflexió que complicava el retallat.

Publicació original: Process API Improvements in .NET 11

Com Copilot Studio Va Migrar a .NET 10 WebAssembly i Va Ser un 20% Més Ràpid

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

L’equip de Copilot Studio va fer alguna cosa sobre la qual tots els desenvolupadors Blazor WASM han tingut curiositat: van actualitzar una aplicació de producció de .NET 8 a .NET 10 i van mesurar els resultats. La publicació comparteix números específics, cosa que és rara i genuïnament útil.

L’Actualització Va Ser Avorrida (Això és Positiu)

Actualitzar el framework de destinació, actualitzar les referències de paquets, corregir els canvis trencadors. Això és tot. La compilació de .NET 10 ara s’executa en producció. La migració en si no va ser la part interessant — els canvis de .NET 10 sí que ho són.

Empremta Digital Automàtica d’Actius

Anteriorment, distribuir una aplicació WASM significava escriure scripts personalitzats per reanomenar els actius publicats amb hashes SHA256 per a la invalidació de caché. Copilot Studio tenia un script PowerShell fent exactament això — reanomenar fitxers, injectar atributs integrity al carregador JavaScript, gestionar tot manualment.

A .NET 10, tot això és integrat. Els actius publicats s’empremten automàticament, s’importen directament de dotnet.js i es validen amb integritat sense intervenció manual. L’equip va eliminar l’script de reanomenament.

Petit canvi en abast, reducció significativa de la complexitat.

WasmStripILAfterAOT Ara Està Activat per Defecte

A .NET 8, eliminar IL de les assemblies compilades AOT era opt-in. A .NET 10 és el valor per defecte. Després de la compilació AOT, el codi de bytes IL original s’elimina de la sortida — no es necessita en temps d’execució, i mantenir-lo inflava la mida del paquet sense raó.

Copilot Studio utilitza una optimització específica: distribueix tant un motor JIT (inici ràpid) com un motor AOT (rendiment màxim en estat estable), carregant ambdós en paral·lel i passant de JIT a AOT un cop està llest. També deduplicà els fitxers idèntics entre els dos motors.

El nou comportament d’eliminació de IL significa que les assemblies AOT ja no coincideixen bit per bit amb les seves contraparts JIT, de manera que menys fitxers es dedupliquen:

.NET 8: 59 fitxers compartits
.NET 10: 22 fitxers compartits

Resultat net: mida del paquet aproximadament un 15% major per al motor AOT. La descàrrega AOT és ~6% més lenta en LAN ràpida, ~17% més lenta en 4G. Però tot passa en segon pla després que l’aplicació ja és interactiva.

Els Números de Rendiment

Aquesta és la part que importa:

~20% més ràpid en la primera crida (camí fred)
~5% més ràpid en crides posteriors (camí calent)

Les millores són més visibles en “bots grans” — agents grans i complexos on el codi compilat AOT domina. Per a fluxos de treball més simples el guany és menor.

Si Encara Esteu a .NET 8

La història de migració és genuïnament senzilla: actualitzeu <TargetFramework>, actualitzeu les referències de paquets, elimineu qualsevol script d’empremtes personalitzat, i us beneficiareu automàticament de WasmStripILAfterAOT. Si esteu compilant AOT, espereu guanys de rendiment similars.

Una nota de la publicació: si carregueu el runtime de .NET WASM dins d’un WebWorker, configureu dotnetSidecar = true en inicialitzar.

Post original: Copilot Studio gets faster with .NET 10 on WebAssembly

Performance | The .NET Blog