.NET 11 finalmente risolve l'API dei Processi

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

Ogni sviluppatore .NET che abbia mai avuto bisogno di avviare un processo e catturarne l’output ha scritto qualche variante dello stesso pericoloso boilerplate: lettura async da stdout, lettura async da stderr, WaitForExitAsync, senza dimenticare di svuotare entrambi gli stream altrimenti si va in deadlock. È una trappola ben nota che esiste da anni.

.NET 11 finalmente la risolve correttamente.

RunAndCaptureTextAsync

L’aggiunta principale: un singolo metodo statico che avvia un processo, cattura stdout e stderr, e attende l’uscita senza deadlock.

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

Una sola chiamata. Nessuno svuotamento manuale degli stream. Nessun WaitForExit posizionato con cura. Se hai solo bisogno di eseguire qualcosa e ottenere il suo output, questa è l’API che vuoi.

C’è anche Process.RunAsync per il caso in cui vuoi aspettare l’uscita senza catturare l’output.

KillOnParentExit

Un problema comune con i processi avviati: se il processo padre si arresta o viene terminato, i processi figli continuano a girare come orfani. KillOnParentExit ti permette di dichiarare all’avvio del processo che il processo figlio deve essere terminato quando il processo padre esce.

Questa è una funzionalità che esisteva in modi specifici per piattaforma (job objects su Windows, prctl su Linux) ma richiedeva p/invoke o librerie di terze parti per essere usata da .NET. Ora è una proprietà di prima classe su ProcessStartInfo.

API Basate su SafeProcessHandle

La nuova superficie API leggera è costruita attorno a SafeProcessHandle piuttosto che alla classe Process completa. La classe Process completa porta molto stato ed è difficile da eliminare — il percorso SafeProcessHandle è più adatto al trimmer per le applicazioni che devono minimizzare le dimensioni dell’output (WASM, AOT nativo).

Controllo Completo sull’Ereditarietà degli Handle

L’aggiornamento aggiunge anche un controllo granulare su quali handle un processo figlio eredita e come vengono reindirizzati gli handle standard. In precedenza potevi reindirizzare stdin/stdout/stderr ma non potevi specificare esattamente quali handle ereditare a livello di SO. Le nuove API espongono quel controllo.

Perché È Importante

La classe Process è usata in tooling, sistemi di build, test runner e qualsiasi applicazione che invoca altri eseguibili. La vecchia superficie API risaliva a .NET Framework e mostrava la sua età. Non è un cambiamento che rompe la compatibilità — le vecchie API funzionano ancora — ma il nuovo codice dovrebbe preferire la nuova superficie.

Per le applicazioni trimmate o gli scenari di compilazione AOT, il percorso SafeProcessHandle è particolarmente benvenuto. La vecchia classe Process portava molto codice pesante di reflection che complicava il trimming.

Post originale: Process API Improvements in .NET 11

Come Copilot Studio È Migrato a .NET 10 WebAssembly e Si È Velocizzato del 20%

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

Il team di Copilot Studio ha fatto qualcosa su cui tutti gli sviluppatori Blazor WASM erano curiosi: hanno effettivamente aggiornato un’applicazione di produzione da .NET 8 a .NET 10 e misurato i risultati. Il post condivide numeri specifici, il che è raro e genuinamente utile.

La Migrazione È Stata Noiosa (Questo è Positivo)

Aggiornare il framework di destinazione, aggiornare i riferimenti ai pacchetti, correggere le modifiche che causano interruzioni. Tutto qui. La build .NET 10 ora è in esecuzione in produzione. La migrazione stessa non era la parte interessante — le modifiche in .NET 10 lo sono.

Fingerprinting Automatico degli Asset

In precedenza, distribuire un’app WASM significava scrivere script personalizzati per rinominare gli asset pubblicati con hash SHA256 per l’invalidazione della cache. Copilot Studio aveva uno script PowerShell che faceva esattamente questo — rinominare i file, iniettare attributi integrity nel loader JavaScript, gestire tutto manualmente.

In .NET 10, tutto ciò è integrato. Gli asset pubblicati vengono automaticamente contrassegnati con fingerprint, importati direttamente da dotnet.js e validati con integrità senza intervento manuale. Il team ha eliminato lo script di rinomina.

Piccolo cambiamento nell’ambito, riduzione significativa della complessità.

WasmStripILAfterAOT Ora È Abilitato per Impostazione Predefinita

In .NET 8, rimuovere IL dagli assembly compilati AOT era opt-in. In .NET 10 è l’impostazione predefinita. Dopo la compilazione AOT, il bytecode IL originale viene rimosso dall’output — non è necessario in fase di runtime, e mantenerlo gonfiava le dimensioni del pacchetto senza motivo.

Copilot Studio usa un’ottimizzazione specifica: distribuisce sia un motore JIT (avvio rapido) sia un motore AOT (massime prestazioni in stato stazionario), caricandoli entrambi in parallelo e passando da JIT ad AOT una volta pronto. Deduplica anche i file identici tra i due motori.

Il nuovo comportamento di stripping dell’IL significa che gli assembly AOT non corrispondono più bit per bit alle loro controparti JIT, quindi meno file vengono deduplicati:

.NET 8: 59 file condivisi
.NET 10: 22 file condivisi

Risultato netto: dimensione del pacchetto circa il 15% maggiore per il motore AOT. Il download AOT è ~6% più lento su LAN veloce, ~17% più lento su 4G. Ma tutto avviene in background dopo che l’app è già interattiva.

I Numeri delle Prestazioni

Questa è la parte che conta:

~20% più veloce alla prima chiamata (percorso freddo)
~5% più veloce nelle chiamate successive (percorso caldo)

I miglioramenti sono più visibili nei “bot grandi” — agenti grandi e complessi dove domina il codice compilato AOT. Per flussi di lavoro più semplici il guadagno è minore.

Se Sei Ancora su .NET 8

La storia di migrazione è genuinamente semplice: aggiorna <TargetFramework>, aggiorna i riferimenti ai pacchetti, rimuovi eventuali script di fingerprinting personalizzati, e beneficerai automaticamente di WasmStripILAfterAOT. Se stai compilando in AOT, aspettati guadagni di prestazioni simili.

Una nota dal post: se carichi il runtime .NET WASM all’interno di un WebWorker, imposta dotnetSidecar = true all’inizializzazione.

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

Performance | The .NET Blog