WebView2 accelera mentre C# 15 e Foundry riducono la distanza tra codice e agenti

🤖 Cosa cambia

• WebView2 Runtime passa da quattro a due settimane tra una major release e l’altra, allineandosi alla nuova cadenza di Microsoft Edge.
• C# 15 introduce union type, gerarchie closed, nuovo modello unsafe, extension indexer e break/continue etichettati in .NET 11 Preview 7.
• Foundry Hosted Agents permette di trasformare un agente C# locale in servizio gestito con un pacchetto NuGet, tre righe e due comandi azd.

Microsoft accelera contemporaneamente browser embedded, linguaggio C# e distribuzione degli agenti AI, avvicinando tre livelli che fino a poco tempo fa vivevano su cicli molto differenti. WebView2 adotterà una nuova major release ogni due settimane, seguendo Edge. C# 15, previsto con .NET 11 a novembre, introduce union type, gerarchie chiuse e la prima fase di una revisione profonda del modello unsafe. Sul fronte AI, Microsoft Foundry Hosted Agents riduce invece il passaggio da una console application costruita con Agent Framework a un agente gestito in Azure a un pacchetto NuGet, tre linee aggiuntive di C# e due comandi. Il denominatore comune è la riduzione dell’attrito tra sviluppo, aggiornamento e messa in produzione.

WebView2 passa da quattro a due settimane tra una major release e l’altra

A partire dalla versione 153, WebView2 Runtime adotterà la stessa cadenza quindicinale di Microsoft Edge. Nel nuovo calendario ufficiale WebView2 Microsoft indica la versione 152, prevista nella settimana del 27 agosto, come ultima major pubblicata quattro settimane dopo la precedente. La versione 153 arriverà invece nella settimana del 10 settembre, soltanto due settimane più tardi, e da quel momento il Runtime dovrebbe ricevere una nuova major all’incirca ogni quattordici giorni. Il cambiamento riguarda un componente molto più importante di quanto suggerisca il nome: WebView2 permette alle applicazioni Windows di incorporare il motore Chromium di Edge e viene utilizzato da software desktop, interfacce ibride e componenti Microsoft. L’accelerazione segue l’evoluzione già vista in Edge e nell’intero stack Microsoft verso cicli di sviluppo sempre più rapidi.

Evergreen non richiede interventi, Fixed Version aumenta il carico di validazione

Per chi utilizza la modalità Evergreen Runtime, che rappresenta l’impostazione predefinita, Microsoft non richiede modifiche operative: i sistemi degli utenti riceveranno automaticamente sicurezza e miglioramenti della piattaforma con la nuova frequenza. La situazione cambia per chi distribuisce una Fixed Version Runtime, dove l’applicazione include o vincola una specifica build. In quel caso le major arriveranno due volte più spesso e i team dovranno accelerare test di regressione, validazione e aggiornamento per evitare di restare indietro sulle correzioni di sicurezza.

Anche il WebView2 SDK cambia modello: non verrà più pubblicato obbligatoriamente ogni mese, ma soltanto quando esisteranno nuove API, fix o miglioramenti, sincronizzandone l’uscita con quella del relativo Runtime. Microsoft raccomanda quindi di usare i canali Beta di Edge e WebDriver per automatizzare i test delle applicazioni embedded. Il modello assomiglia sempre più a quello del browser moderno: aggiornamenti rapidi e continui in cambio di una pipeline di test altrettanto continua.

C# 15 introduce union type direttamente nel type system

Sul fronte linguaggio, Microsoft ha pubblicato una prima panoramica organica di C# 15, disponibile in .NET 11 Preview 7 e previsto in versione finale insieme a .NET 11 a novembre. La novità più visibile è l’introduzione dei union type, che permettono di dichiarare esplicitamente che un valore può appartenere soltanto a un insieme determinato di tipi. Nel post ufficiale dedicato a C# 15 Microsoft utilizza l’esempio di una union Pet(Cat, Dog, Bird): il compilatore conosce tutti i casi ammessi e può quindi considerare esaustivo uno switch senza richiedere un ramo generico. È un cambiamento importante per modellare stati, risultati e payload eterogenei senza ricorrere a object, interfacce marker o gerarchie artificiali. L’evoluzione continua il percorso iniziato con C# 14 e l’espansione delle capacità del linguaggio dentro .NET, ma porta nel sistema di tipi una forma di espressività molto più vicina a quella dei linguaggi funzionali moderni.

Le gerarchie closed limitano esplicitamente chi può ereditare

Accanto alle union arrivano le closed hierarchies. Il nuovo modificatore closed rende una classe implicitamente astratta e limita i tipi derivati diretti all’assembly che la dichiara. Il vantaggio è simile a quello delle union: il compilatore e lo sviluppatore conoscono l’intero spazio dei casi possibili. Una gerarchia JobStatus, ad esempio, può ammettere soltanto stati come Queued, Running, Completed e Failed. Per applicazioni complesse, workflow agentici e state machine, questo riduce la possibilità che nuovi tipi inattesi rendano incompleta la logica di pattern matching. Union type, closed hierarchy e i futuri closed enum condividono quindi la stessa filosofia: spostare più invarianti dal codice applicativo al compilatore. È particolarmente utile mentre .NET evolve verso sistemi sempre più agentici e distribuiti, terreno già anticipato con Microsoft Agent Framework e il consolidamento degli strumenti per applicazioni AI.

Il modello unsafe viene ripensato come contratto e non semplice marcatore sintattico

La modifica più profonda di C# 15 è però ancora in preview e riguarda la memory safety. Microsoft vuole trasformare unsafe da semplice segnale che “qui esistono puntatori” a un vero contratto tra chiamante, compilatore e API. Nel modello sperimentale alcune operazioni, come dichiarare un tipo puntatore, ottenere un indirizzo, usare fixed, convertire stackalloc o applicare sizeof a un tipo unmanaged, non richiedono più automaticamente un contesto unsafe. Continuano invece a richiederlo le operazioni che effettivamente dereferenziano o invocano attraverso puntatori. Ancora più importante, un metodo che espone unsafe nella firma potrà essere chiamato soltanto da un contesto unsafe, propagando esplicitamente la responsabilità al chiamante. Il design non è definitivo e Microsoft avverte che potrebbe cambiare ancora con C# 16 e .NET 12, ma l’obiettivo è chiaramente ridurre la zona grigia tra codice sicuro e codice che il compilatore non può verificare.

Collection expression, indexer estesi e loop etichettati riducono codice cerimoniale

C# 15 aggiunge anche modifiche meno rivoluzionarie ma immediatamente utilizzabili. Le collection expression possono ricevere argomenti attraverso il nuovo elemento with(...), permettendo di specificare capacità o comparer direttamente durante la costruzione. Gli extension indexer estendono invece il lavoro iniziato da C# 14 sugli extension member: un tipo può essere indicizzato attraverso un indexer dichiarato esternamente senza introdurre un metodo helper. Arrivano infine break e continue con label applicate direttamente ai loop, soluzione che evita flag, goto o estrazione di metodi quando bisogna uscire da cicli annidati. Nel complesso C# 15 cerca meno l’effetto spettacolare e più la riduzione della complessità accidentale, mentre .NET 11 è passato dalle prime Preview a una piattaforma sempre più completa.

Foundry elimina il secondo progetto necessario per mettere online un agente

Il terzo annuncio affronta un problema molto più operativo: come passare da un agente funzionante in locale a un servizio disponibile in produzione. Fino a oggi un’app console costruita con Microsoft Agent Framework richiedeva normalmente container, server HTTP, autenticazione, session storage, scaling, osservabilità e gestione del lifecycle. Nel tutorial ufficiale sui Foundry Hosted Agents Microsoft mostra come conservare invariata la logica dell’AIAgent e aggiungere un solo pacchetto, Microsoft.Agents.AI.Foundry.Hosting, insieme a tre linee di C#: AgentHost.CreateBuilder, AddFoundryResponses e RegisterProtocol. Il risultato espone un endpoint /responses compatibile con il protocollo OpenAI senza dover costruire manualmente Kestrel, gestione delle conversazioni o streaming. È la concretizzazione operativa del percorso iniziato con Microsoft Agent Framework come base unificata per agenti e workflow AI.

Due comandi azd creano infrastruttura, identità e deployment

Dopo il test locale, il deployment viene ridotto essenzialmente a azd provision e azd deploy. Il primo comando crea resource group, istanza Foundry, progetto, model deployment, Application Insights e Azure Container Registry; il secondo costruisce il container, lo pubblica nel registry e registra l’agente nel Foundry Agent Service. Ogni agente riceve automaticamente un endpoint dedicato e una propria identità Microsoft Entra, mentre la piattaforma gestisce session state, scaling to zero, versioni immutabili, rollback, tracing OpenTelemetry ed evaluation. Le sessioni vengono deprovisionate dopo 15 minuti di inattività conservandone lo stato per il successivo ripristino. Foundry Hosted Agents supporta inoltre strumenti come Code Interpreter, web search, Azure AI Search, MCP e A2A attraverso un endpoint MCP consolidato. La promessa è quindi molto più ampia delle “tre righe”: Microsoft vuole togliere agli sviluppatori l’intero strato infrastrutturale necessario per trasformare una demo agentica in un servizio gestito.

Microsoft comprime sempre di più la distanza tra linguaggio, runtime e cloud

I tre annunci sembrano indipendenti, ma descrivono la stessa strategia. WebView2 accelera il ritmo con cui il runtime Web entra nelle applicazioni Windows. C# 15 sposta più garanzie direttamente nel type system e prova a rendere più esplicito il confine della memoria non sicura. Foundry Hosted Agents riduce invece il numero di passaggi tra codice locale e infrastruttura cloud. Il risultato è uno stack nel quale aggiornamento, linguaggio e deployment si muovono tutti più velocemente e con meno cerimoniale manuale. Per gli sviluppatori il vantaggio è evidente, ma aumenta anche la necessità di automazione. Una WebView2 major ogni due settimane richiede test continui; C# 15 introduce feature che cambiano il modo di modellare tipi e sicurezza; Foundry rende semplicissimo creare infrastruttura Azure, ma proprio per questo identity, costi, telemetria e governance entrano nel progetto quasi automaticamente. Microsoft sta riducendo la distanza tra dotnet run e produzione. La sfida successiva sarà assicurarsi che quella distanza diventi più breve senza diventare anche meno visibile.