Con il rilascio della Preview 4, .NET 11 entra ufficialmente nella fase in cui "il gioco si fa serio". Abbiamo superato il periodo puramente sperimentale per entrare nel territorio delle funzionalità concrete. L'infrastruttura sottostante ai tuoi servizi web e ai front-end Blazor è diventata più snella, veloce e decisamente più facile da debuggare.

Se stai pianificando la tua roadmap di modernizzazione del software, questa preview è il segnale chiaro che è arrivato il momento di mettere .NET 11 sul radar.

Le Novità Principali di Preview 4

La Preview 4 si concentra meno sugli annunci da prima pagina e più sulla limatura degli angoli smussati, introducendo però un paio di svolte decisive sull'async a livello di runtime.

1. L'Async di Runtime entra nel Framework Condiviso

Il segnale più importante di questa build è che le librerie del framework condiviso (BCL e lo stack di ASP.NET Core) sono ora compilate nativamente con l'async di runtime attivo. Nelle Preview 1–3 si trattava di una feature opzionale per il proprio codice; ora è lo standard del framework.

1. Perché è importante: Ogni "salto" asincrono attraverso Kestrel, la pipeline, l'HTTP client ed EF Core sfrutta ora la macchina asincrona nativa del runtime, anziché la macchina a stati generata dal compilatore.
2. Il vantaggio per i sistemi legacy: Le applicazioni modernizzate (ad esempio da PowerBuilder o VB6) tendono a essere estremamente "logorroiche" sulle operazioni di I/O asincrono. Stack trace più puliti e una minore pressione sull'allocazione della memoria si faranno sentire lungo tutta la pipeline.

2. Supporto al metodo HTTP QUERY in OpenAPI 3.2

Il metodo HTTP QUERY (un verbo simile a GET ma dotato di un corpo della richiesta) è ora riconosciuto nella generazione OpenAPI di ASP.NET Core.

1. Se imposti OpenApiVersion = 3.2, il documento generato emetterà un campo inline query Path Item.
2. Per la retrocompatibilità con OpenAPI 3.0 e 3.1, il generatore utilizzerà l'estensione x-oai-additionalOperations.

Caso d'uso: Endpoint di ricerca o reportistica complessi (spesso derivati da vecchie app Clarion o Access) che superano facilmente i limiti di lunghezza degli URL per i parametri di query. Con QUERY puoi inviare la struttura del filtro nel body senza perdere chiarezza semantica.

3. Osservabilità dell'Handshake TLS

Se hai mai perso un intero pomeriggio a capire perché un partner di integrazione o un vecchio dispositivo industriale rifiutasse di comunicare con la tua API modernizzata, apprezzerai queste aggiunte diagnostiche:

1. UseTlsClientHelloListener: Un nuovo metodo di estensione per ispezionare il ClientHello grezzo prima del completamento della negoziazione TLS.
2. ITlsHandshakeFeature.Exception: Una proprietà esposta tramite middleware di connessione per loggare il motivo esatto del fallimento di un handshake.

4. Filtri degli Endpoint e Failure di Binding

Fino ad ora, i filtri degli endpoint nelle Minimal API venivano eseguiti dopo il binding dei parametri. Se il binding generava un errore 400 (Bad Request), il filtro non lo vedeva mai.

1. La soluzione: Impostando RouteHandlerOptions.ThrowOnBadRequest = false, il tuo filtro potrà intercettare il fallimento del binding e decidere come rispondere (es. loggare l'evento, trasformare la risposta o personalizzare l'errore). Questa correzione verrà portata anche su .NET 10.0.8.

5. Blazor Virtualize fa sul serio

Il componente Virtualize riceve due importanti aggiornamenti per la gestione dei flussi di dati reali:

1. Altezze variabili: Gestite correttamente anche sopra il viewport. Le operazioni di prepend (aggiunta in testa) non faranno più sobbalzare o scorrere l'ancoraggio dello scroll.
2. Parametro AnchorMode: Un nuovo enum [Flags] con opzioni Beginning (per feed di notizie/notifiche dove la parte superiore deve rimanere ferma) ed End (per chat o log che devono rimanere ancorati all'ultimo elemento inserito).

Il Quadro Generale: I 4 Grandi Temi di .NET 11

Guardando lo sviluppo di .NET 11 nel suo insieme, emergono chiaramente quattro direttrici strategiche:

1. Async integrato nel Runtime:Riduzione drastica "del rumore" negli stack trace (i profiler vedono i reali frame dei metodi e non i plumbing della macchina a stati), meno pressione sul Garbage Collector e spinta decisiva per Native AOT.
2. WebAssembly su CoreCLR:Blazor WASM si sposta progressivamente da Mono a un RyuJIT dedicato a WebAssembly. In futuro, server e browser condivideranno lo stesso identico motore di esecuzione ottimizzato.
3. Compressione, AI e Nuova Sintassi:Supporto nativo a Zstandard (da 2 a 7 volte più veloce in compressione rispetto a gzip); introduzione del tipo BFloat16 per carichi AI; ricerca vettoriale in EF Core 11; introduzione dei Union Types in C# 15.
4. SDK e Tooling Potenziati:dotnet run diventa interattivo; supporto per variabili d'ambiente in linea (dotnet run -e KEY=value); dotnet watch si integra nativamente con i nodi Aspire; immagini container ridotte fino al 17%.

Cosa significa questo per i Team di Sviluppo?

Se stai definendo la roadmap tecnologica della tua azienda, tieni a mente questi tre punti:

1. Punta direttamente a .NET 11 per i nuovi progetti di modernizzazione: Anche se .NET 10 è una versione LTS, i miglioramenti all'async di runtime, la convergenza WASM e le ottimizzazioni di Blazor in .NET 11 sono esattamente ciò di cui beneficia un'applicazione appena riscritta.
2. Pianifica un pass di regressione per l'async: Poiché la Preview 4 attiva l'async di runtime all'interno del framework condiviso, eventuali comportamenti imprevisti nelle librerie di terze parti o nel codice asincrono profondo sono i primi dettagli da monitorare nei test di accettazione.
3. Rivaluta Blazor WASM nel 2027: Se in passato hai scelto Blazor Server solo per motivi di performance o tempi di avvio di WASM, l'arrivo di CoreCLR su WebAssembly cambierà radicalmente le regole del gioco.

Risorse Utili e Prossimi Passi

1. Download SDK Preview 4: dotnet.microsoft.com/download/dotnet/11.0
2. Note di rilascio ufficiali: Repository dotnet/core su GitHub.
3. Lancio GA (General Availability): Novembre 2026 durante la .NET Conf.

Il ritmo di rilascio prevede ora una preview al mese per tutta l'estate, seguita dalle Release Candidate a settembre e ottobre. Questo offre ai team una finestra ideale per testare le proprie applicazioni sui bit della Preview 5 o 6 ed essere pronti per il rollout autunnale.