Microsoft Copilot Studio è uno strumento di low-code per la creazione di agenti AI, e uno dei suoi punti di forza è l’esecuzione di logica C# direttamente nel browser tramite .NET WebAssembly (WASM). Di recente, il team di Copilot Studio ha completato la migrazione del motore WASM da .NET 8 a .NET 10 — e i risultati sono più che soddisfacenti. In questo articolo analizziamo in dettaglio cosa è cambiato, perché vale la pena migrare anche per le vostre applicazioni Blazor e WebAssembly, e quali ottimizzazioni concrete offre .NET 10 in questo ambito.
Il contesto: C# nel browser con .NET WebAssembly
Qualche mese fa il team di Copilot Studio aveva già pubblicato un post tecnico su come utilizzano .NET e WebAssembly per eseguire codice C# nel browser, mostrando i guadagni ottenuti passando da .NET 6 a .NET 8. Ora il ciclo si ripete con il salto a .NET 10, e la migrazione è stata descritta come sorprendentemente semplice.
Aggiornare un’applicazione WASM da .NET 8 a .NET 10 è sostanzialmente una questione di modificare il TargetFramework nei file .csproj e verificare la compatibilità delle dipendenze. Per Copilot Studio, il percorso è stato esattamente questo, e il build .NET 10 è già in produzione.
Fingerprinting automatico degli asset: addio script PowerShell personalizzati
Una delle novità più apprezzate di .NET 10 per le applicazioni WebAssembly è il fingerprinting automatico degli asset WASM. Quando si pubblica un’applicazione WebAssembly, ogni risorsa include ora un identificatore univoco nel nome del file, garantendo sia il cache-busting che l’integrità senza alcun intervento manuale.
Prima di .NET 10, Copilot Studio — come molte app WASM — doveva:
- Leggere il manifest
blazor.boot.jsonpubblicato per enumerare tutti gli asset. - Eseguire uno script PowerShell personalizzato per rinominare ogni file aggiungendo un hash SHA256.
- Passare un argomento
integrityesplicito lato JavaScript al momento del caricamento di ogni risorsa.
Con .NET 10, tutto questo è storia. Le risorse vengono importate direttamente da dotnet.js, i fingerprint fanno parte dei nomi di file pubblicati, e l’integrità è validata automaticamente. Il team ha potuto eliminare lo script di rinomina personalizzato e rimuovere l’argomento integrity dal loader JavaScript lato client.
Tip: Se caricate il runtime .NET WASM all’interno di un
WebWorker, impostatedotnetSidecar = truedurante l’inizializzazione per garantire il corretto avvio nel contesto worker.
Output AOT più piccolo con WasmStripILAfterAOT
L’altra novità di spicco per .NET WASM in .NET 10 è che WasmStripILAfterAOT è ora abilitato per default per le build AOT. Dopo la compilazione ahead-of-time dei metodi .NET in WebAssembly, il codice IL (Intermediate Language) originale non è più necessario a runtime: .NET 10 lo elimina dall’output pubblicato per default. In .NET 8 questa impostazione esisteva ma era disattivata.
Copilot Studio adotta una strategia di packaging più sofisticata. Per ottenere il meglio sia in termini di avvio rapido che di performance a regime, spedisce un singolo pacchetto NPM che contiene sia un motore JIT (per l’avvio veloce) che un motore AOT (per la massima velocità di esecuzione). A runtime, Copilot Studio carica JIT e AOT in parallelo: il motore JIT gestisce le interazioni iniziali, poi cede il controllo all’AOT non appena è pronto. I file identici tra i due modi vengono deduplicati per mantenere il pacchetto compatto.
Poiché WasmStripILAfterAOT produce assembly AOT che non corrispondono più alle controparti JIT, meno file possono essere condivisi tra i due motori:
- Su .NET 8: 59 file condivisi tra JIT e AOT.
- Su .NET 10: solo 22 file condivisi.
L’effetto netto sul pacchetto Copilot Studio è un aumento di dimensione di circa il 15%. In pratica l’impatto per gli utenti finali è contenuto, poiché il motore JIT resta quello scaricato ed eseguito per primo: l’interattività iniziale non è compromessa. Il download AOT è circa 6% (~200 ms) più lento su una LAN veloce e circa 17% (~5 secondi) più lento su una connessione 4G — tutto in background, dopo che l’app è già operativa.
I risultati di performance
I benefici a runtime superano ampiamente il costo in termini di packaging per i workload di Copilot Studio:
- ~20% più veloce nell’esecuzione alla prima chiamata (cold path).
- ~5% più veloce nelle chiamate successive (warm path).
I guadagni sono più visibili negli agenti grandi e complessi (“big bots”), dove il codice AOT compilato fa il grosso del lavoro. Per workload più semplici i miglioramenti sono comunque presenti ma più contenuti.
Come migrare la vostra app a .NET 10
Se avete un’applicazione Blazor o .NET WebAssembly su .NET 8, vale la pena provare .NET 10. Ecco i passi essenziali:
- Aggiornate
<TargetFramework>anet10.0e aggiornate i riferimenti a pacchettiMicrosoft.AspNetCore.*,Microsoft.Extensions.*eSystem.*. - Rimuovete eventuale logica personalizzata di rinomina degli asset o plumbing per l’
integrity— il fingerprinting è ora integrato. - Se compilate in AOT, beneficerete automaticamente del nuovo default
WasmStripILAfterAOT.
Se avete bisogno di supporto per l’aggiornamento, GitHub Copilot app modernization for .NET può analizzare la soluzione, pianificare l’aggiornamento e applicare le modifiche necessarie.
Conclusione
La migrazione di Copilot Studio a .NET 10 è l’ennesima conferma che ogni release di .NET porta WebAssembly a essere più veloce, più leggero e più semplice da distribuire. La rimozione dello script di fingerprinting personalizzato è un piccolo ma significativo esempio di come il framework stia maturando: quello che prima richiedeva custom tooling è ora built-in. Se state ancora su .NET 8, questo è il momento giusto per valutare il salto.
Fonte: Copilot Studio gets faster with .NET 10 on WebAssembly — Daniel Roth, .NET Blog