Dotnet | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 si svolge dall’11 al 15 maggio 2026 al Barbican Centre di Londra. La conferenza principale di 3 giorni va da martedì a giovedì, con workshop opzionali di un’intera giornata il lunedì e il venerdì.

Con 78 sessioni e 14 workshop, è una delle conferenze per sviluppatori più ricche d’Europa.

Argomenti

Pensiero Architetturale
Codice Funzionale in C# 13
Design Serverless
IA Semantica
Azure Kubernetes Services
Strategie Lean DevOps
The Model Context Protocol (MCP)
IA Agentica in .NET
Refactoring del Monolite
Programmare Più Velocemente con gli LLM
Crittografia in un Mondo Post-Quantistico
Sviluppo Local First

Speaker

Lineup di classe mondiale che include Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm e Raju Gandhi.

Biglietti e informazioni

Il 98% dei partecipanti di SDD 2025 ha valutato l’esperienza complessiva come buona, molto buona o eccellente.

Hook azd in Python, TypeScript e .NET: basta script shell

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se hai mai avuto un progetto completamente in .NET e ti sei ritrovato a scrivere script Bash solo per gli hook di azd, conosci bene quella sensazione. Perché passare alla sintassi shell per un passaggio di pre-provisioning quando tutto il resto del progetto è in C#?

Quella frustrazione ha ora una soluzione ufficiale. La CLI di Azure Developer ha appena introdotto il supporto multi-linguaggio per gli hook, ed è esattamente buono come sembra.

Gli hook, in breve

Gli hook sono script eseguiti in punti chiave del ciclo di vita di azd — prima del provisioning, dopo il deployment, e altro ancora. Definiti in azure.yaml, permettono di iniettare logica personalizzata senza modificare la CLI.

Prima erano supportati solo Bash e PowerShell. Ora si può usare Python, JavaScript, TypeScript o .NET — e azd si occupa del resto automaticamente.

Come funziona il rilevamento

Basta puntare l’hook verso un file e azd deduce il linguaggio dall’estensione:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Nessuna configurazione aggiuntiva. Se l’estensione è ambigua, si può aggiungere kind: python (o il linguaggio appropriato) per specificarlo esplicitamente.

Dettagli per linguaggio

Python

Inserire un requirements.txt o pyproject.toml vicino allo script (o in una directory padre). azd crea automaticamente un ambiente virtuale, installa le dipendenze ed esegue lo script.

JavaScript e TypeScript

Stesso schema — un package.json vicino allo script e azd esegue prima npm install. Per TypeScript, usa npx tsx senza step di compilazione né tsconfig.json.

.NET

Due modalità disponibili:

Modalità progetto: Se c’è un .csproj vicino allo script, azd esegue automaticamente dotnet restore e dotnet build.
Modalità single-file: Con .NET 10+, i file .cs autonomi vengono eseguiti direttamente via dotnet run script.cs. Nessun file di progetto richiesto.

Configurazione per executor

Ogni linguaggio supporta un blocco config opzionale:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Perché è importante per gli sviluppatori .NET

Gli hook erano l’ultimo posto in un progetto basato su azd che costringeva a cambiare linguaggio. Ora l’intera pipeline di deployment può vivere in un unico linguaggio. È possibile riutilizzare le utility .NET esistenti negli hook, referenziare librerie condivise ed eliminare la manutenzione di script shell.

Conclusione

Uno di quei cambiamenti che sembrano piccoli ma che riducono concretamente la frizione quotidiana con azd. Il supporto multi-linguaggio per gli hook è disponibile ora — tutti i dettagli nel post ufficiale.

Windows App Dev CLI v0.3: F5 dal terminale e UI Automation per gli agenti

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

L’esperienza F5 di Visual Studio è fantastica. Ma dover aprire VS solo per avviare e fare debug di un’app Windows pacchettizzata è eccessivo — che si tratti di una pipeline CI, di un workflow automatizzato o di un agente AI che esegue i test.

Windows App Development CLI v0.3 è appena uscita e lo affronta direttamente con due funzionalità principali: winapp run e winapp ui.

winapp run: F5 da qualsiasi posto

winapp run prende una cartella di app non pacchettizzata e un manifesto, e fa tutto ciò che VS fa nel debug launch: registra un pacchetto loose, avvia l’app e preserva il LocalState tra i re-deploy.

# Compila l'app, poi avviala come app pacchettizzata
winapp run ./bin/Debug

Funziona per WinUI, WPF, WinForms, Console, Avalonia e altro. Le modalità sono pensate per sviluppatori e workflow automatizzati:

--detach: Avvia e restituisce il controllo al terminale immediatamente. Perfetto per CI.
--unregister-on-exit: Pulisce il pacchetto registrato alla chiusura dell’app.
--debug-output: Cattura i messaggi OutputDebugString e le eccezioni in tempo reale.

Nuovo pacchetto NuGet: dotnet run per le app pacchettizzate

Per gli sviluppatori .NET c’è un nuovo pacchetto NuGet: Microsoft.Windows.SDK.BuildTools.WinApp. Dopo l’installazione, dotnet run gestisce tutto l’inner loop: build, preparare un pacchetto loose-layout, registrare su Windows e avviare — tutto in un unico step.

winapp init
# o
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: UI Automation dalla riga di comando

Questa è la funzionalità che apre gli scenari agentici. winapp ui fornisce accesso completo UI Automation a qualsiasi app Windows in esecuzione — WPF, WinForms, Win32, Electron, WinUI3 — direttamente dal terminale.

Cosa si può fare:

Elencare tutte le finestre di primo livello
Navigare l’albero completo di UI Automation di una finestra
Cercare elementi per nome, tipo o ID di automazione
Cliccare, invocare e impostare valori
Fare screenshot
Attendere la comparsa di elementi — ideale per la sincronizzazione dei test

Combinare winapp ui con winapp run crea un workflow completo build → avvio → verifica dal terminale. Un agente può eseguire l’app, ispezionare lo stato dell’UI e validare il risultato.

Altre novità

winapp unregister: Rimuove un pacchetto sideloaded quando si è finito.
winapp manifest add-alias: Aggiunge un alias per avviare l’app per nome dal terminale.
Tab completion: Configura il completamento PowerShell con un singolo comando.

Come ottenerlo

winget install Microsoft.WinAppCli
# o
npm install -g @microsoft/winappcli

La CLI è in preview pubblica. Il repository su GitHub ha la documentazione completa e l’annuncio originale ha tutti i dettagli.

Smetti di sorvegliare il tuo terminale: la modalità detached di Aspire cambia il flusso di lavoro

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Ogni volta che esegui un AppHost di Aspire, il tuo terminale sparisce. Bloccato. Occupato finché non premi Ctrl+C. Devi eseguire un comando veloce? Apri un’altra scheda. Vuoi controllare i log? Un’altra scheda. È una piccola frizione che si accumula in fretta.

Aspire 13.2 risolve questo problema. James Newton-King ha scritto tutti i dettagli, e onestamente, questa è una di quelle funzionalità che cambia immediatamente il modo in cui lavori.

Modalità detached: un comando, terminale recuperato

aspire start

Questa è la scorciatoia per aspire run --detach. Il tuo AppHost si avvia in background e riottieni il terminale immediatamente. Niente schede extra. Niente multiplexer di terminale. Solo il tuo prompt, pronto all’uso.

Gestire ciò che è in esecuzione

Il punto è questo — eseguire in background è utile solo se riesci a gestire ciò che c’è là fuori. Aspire 13.2 include un set completo di comandi CLI proprio per questo:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Questo trasforma il CLI di Aspire in un vero gestore di processi. Puoi avviare più AppHost, controllare il loro stato, seguire i loro log e spegnerli — tutto da un’unica sessione di terminale.

Combinalo con la modalità isolata

La modalità detached si abbina naturalmente con la modalità isolata. Vuoi eseguire due istanze dello stesso progetto in background senza conflitti di porta?

aspire start --isolated
aspire start --isolated

Ognuna ottiene porte casuali, secret separati e il proprio ciclo di vita. Usa aspire ps per vedere entrambe, aspire stop per fermare quella di cui non hai più bisogno.

Perché questo è enorme per gli agenti di codice

Qui diventa davvero interessante. Un agente di codice che lavora nel tuo terminale ora può:

Avviare l’app con aspire start
Interrogare il suo stato con aspire describe
Controllare i log con aspire logs per diagnosticare problemi
Fermarla con aspire stop quando ha finito

Tutto senza perdere la sessione del terminale. Prima della modalità detached, un agente che eseguiva il tuo AppHost si bloccava nel proprio terminale. Ora può avviare, osservare, iterare e ripulire — esattamente come vorresti che funzionasse un agente autonomo.

Il team di Aspire ha puntato su questo. Eseguire aspire agent init configura un file di skill di Aspire che insegna questi comandi agli agenti. Così strumenti come l’agente di codice di Copilot possono gestire i tuoi workload Aspire direttamente.

Per concludere

La modalità detached è un upgrade del flusso di lavoro mascherato da semplice flag. Smetti di cambiare contesto tra i terminali, gli agenti smettono di bloccarsi da soli, e i nuovi comandi CLI ti danno visibilità reale su ciò che è in esecuzione. È pratico, è pulito, e rende il ciclo di sviluppo quotidiano notevolmente più fluido.

Leggi il post completo per tutti i dettagli e scarica Aspire 13.2 con aspire update --self.

Il Pin Clustering Arriva Finalmente in .NET MAUI Maps — Una Proprietà, Zero Problemi

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Conosci quel momento in cui carichi una mappa con un centinaio di pin e tutto diventa una macchia illeggibile? Sì, questa è stata l’esperienza con .NET MAUI Maps fino ad ora. Non più.

David Ortinau ha appena annunciato che .NET MAUI 11 Preview 3 include il pin clustering out of the box su Android e iOS/Mac Catalyst. E la parte migliore — è ridicolmente semplice da attivare.

Una proprietà per dominarli tutti

<maps:Map IsClusteringEnabled="True" />

Tutto qui. I pin vicini vengono raggruppati in cluster con un badge di conteggio. Zoom in e si espandono. Zoom out e si raggruppano. Il tipo di comportamento che gli utenti si aspettano da qualsiasi mappa moderna — e ora lo ottieni con una singola proprietà.

Gruppi di clustering indipendenti

Ecco dove diventa interessante. Non tutti i pin dovrebbero raggrupparsi insieme. Le caffetterie e i parchi sono cose diverse, e la tua mappa dovrebbe saperlo.

La proprietà ClusteringIdentifier ti permette di separare i pin in gruppi indipendenti:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

I pin con lo stesso identificatore si raggruppano insieme. Identificatori diversi formano cluster indipendenti anche quando sono geograficamente vicini. Nessun identificatore? Gruppo predefinito. Pulito e prevedibile.

Gestione dei tap sui cluster

Quando un utente tocca un cluster, ricevi un evento ClusterClicked con tutto ciò di cui hai bisogno:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Gli argomenti dell’evento ti danno Pins (i pin nel cluster), Location (il centro geografico) e Handled (impostalo su true se vuoi sovrascrivere lo zoom predefinito). Semplice, pratico, esattamente quello che ti aspetteresti.

Dettagli di piattaforma da conoscere

Su Android, il clustering usa un algoritmo personalizzato basato su griglia che ricalcola ai cambi di zoom — nessuna dipendenza esterna. Su iOS e Mac Catalyst, sfrutta il supporto nativo di MKClusterAnnotation di MapKit, il che significa animazioni fluide e native della piattaforma.

Questo è uno di quei casi in cui il team MAUI ha fatto la scelta giusta — appoggiarsi alla piattaforma dove ha senso.

Perché è importante

Il pin clustering è stata una delle funzionalità più richieste in .NET MAUI (issue #11811), e a buon ragione. Ogni app che mostra posizioni su una mappa — tracciamento consegne, localizzatori di negozi, immobiliare — ne ha bisogno. Prima dovevi costruirlo da solo o integrare una libreria di terze parti. Ora è integrato.

Per noi sviluppatori .NET che costruiamo app mobile multipiattaforma, questo è il tipo di miglioramento della qualità della vita che rende MAUI una scelta genuinamente pratica per scenari con uso intensivo di mappe.

Per iniziare

Installa .NET 11 Preview 3 e aggiorna il workload .NET MAUI. L’esempio Maps include una nuova pagina Clustering con cui puoi giocare subito.

Vai a costruire qualcosa — e lascia che le tue mappe finalmente respirino.

.NET Aprile 2026 Servicing — Patch di sicurezza da applicare oggi

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Gli aggiornamenti di servicing di aprile 2026 per .NET e .NET Framework sono disponibili, e questo include correzioni di sicurezza che vorrai applicare presto. Sei CVE corrette, incluse due vulnerabilità di esecuzione di codice remoto (RCE).

Cosa è stato corretto

Ecco il riepilogo rapido:

CVE	Tipo	Interessa
CVE-2026-26171	Bypass delle funzionalità di sicurezza	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Esecuzione di codice remoto	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Esecuzione di codice remoto	.NET 10, 9, 8
CVE-2026-32203	Denial of Service	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Denial of Service	.NET Framework 3.0–4.8.1
CVE-2026-32226	Denial of Service	.NET Framework 2.0–4.8.1

Le due CVE RCE (CVE-2026-32178 e CVE-2026-33116) interessano la gamma più ampia di versioni .NET e dovrebbero essere la priorità.

Versioni aggiornate

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Tutte sono disponibili attraverso i canali abituali — dotnet.microsoft.com, immagini container su MCR e gestori di pacchetti Linux.

Cosa fare

Aggiorna i tuoi progetti e le pipeline CI/CD alle ultime versioni con patch. Se stai usando container, scarica le immagini più recenti. Se sei su .NET Framework, controlla le note di rilascio di .NET Framework per le patch corrispondenti.

Per chi sta eseguendo .NET 10 in produzione (è la versione corrente), 10.0.6 è un aggiornamento obbligatorio. Lo stesso vale per .NET 9.0.15 e .NET 8.0.26 se sei su quelle versioni LTS. Due vulnerabilità RCE non sono qualcosa che si rimanda.

Azure MCP Server 2.0 è Arrivato — L'Automazione Agentica Self-Hosted nel Cloud È Qui

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

Se hai costruito qualcosa con MCP e Azure di recente, probabilmente sai già che l’esperienza locale funziona bene. Connetti un server MCP, lascia che il tuo agente AI parli alle risorse Azure, e vai avanti. Ma nel momento in cui hai bisogno di condividere questa configurazione con un team? Ecco dove le cose si complicavano.

Non più. Azure MCP Server ha appena raggiunto la versione 2.0 stabile, e la feature principale è esattamente quello che i team enterprise chiedevano: supporto per server MCP remoti self-hosted.

Che cos’è Azure MCP Server?

Un rapido ripasso. Azure MCP Server implementa la specifica Model Context Protocol ed espone le capacità di Azure come tool strutturati e scopribili che gli agenti AI possono invocare. Pensalo come un ponte standardizzato tra il tuo agente e Azure — provisioning, deployment, monitoring, diagnostica, tutto attraverso un’interfaccia coerente.

I numeri parlano da soli: 276 tool MCP su 57 servizi Azure. È una copertura seria.

Il grande affare: deployment remoti self-hosted

Ecco il punto. Eseguire MCP localmente sulla tua macchina va bene per lo sviluppo e gli esperimenti. Ma in uno scenario di team reale, hai bisogno di:

Accesso condiviso per sviluppatori e sistemi agentici interni
Configurazione centralizzata (contesto tenant, impostazioni di sottoscrizione predefinite, telemetria)
Limiti di rete e policy aziendali
Integrazione nelle pipeline CI/CD

Azure MCP Server 2.0 affronta tutto questo. Puoi deployarlo come servizio interno gestito centralmente con trasporto basato su HTTP, autenticazione adeguata e governance coerente.

Per l’autenticazione, hai due solide opzioni:

Managed Identity — quando eseguito insieme a Microsoft Foundry
On-Behalf-Of (OBO) flow — delegazione OpenID Connect che chiama le API Azure usando il contesto dell’utente autenticato

Quel flusso OBO è particolarmente interessante per noi sviluppatori .NET. Significa che i tuoi workflow agentici possono operare con i permessi effettivi dell’utente, non con un account di servizio sovra-privilegiato. Principio del minimo privilegio, integrato fin dall’inizio.

Hardening della sicurezza

Non è solo un rilascio di feature — è anche uno di sicurezza. Il rilascio 2.0 aggiunge:

Validazione endpoint più forte
Protezioni contro i pattern di injection negli strumenti orientati alle query
Controlli di isolamento più rigidi per gli ambienti di sviluppo

Se stai per esporre MCP come servizio condiviso, questi salvaguardi contano. Molto.

Dove puoi usarlo?

La storia della compatibilità client è ampia. Azure MCP Server 2.0 funziona con:

IDE: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agenti CLI: GitHub Copilot CLI, Claude Code
Standalone: server locale per configurazioni semplici
Self-hosted remote: la nuova stella del 2.0

Inoltre c’è il supporto per sovereign cloud per Azure US Government e Azure gestito da 21Vianet, che è critico per i deployment regolamentati.

Perché questo conta per gli sviluppatori .NET

Se stai costruendo applicazioni agentiche con .NET — che sia Semantic Kernel, Microsoft Agent Framework, o la tua orchestrazione personalizzata — Azure MCP Server 2.0 ti dà un modo production-ready per lasciare che i tuoi agenti interagiscano con l’infrastruttura Azure. Nessun wrapper REST personalizzato. Nessun pattern di integrazione specifico per il servizio. Solo MCP.

Combinato con l’API fluent per MCP Apps uscito pochi giorni fa, l’ecosistema .NET MCP sta maturando velocemente.

Per iniziare

Scegli il tuo percorso:

GitHub Repo — codice sorgente, documentazione, tutto
Docker Image — deployment containerizzato
VS Code Extension — integrazione IDE
Self-hosting guide — la feature principale del 2.0

Per concludere

Azure MCP Server 2.0 è esattamente il tipo di upgrade infrastrutturale che non sembra vistoso in una demo ma cambia tutto nella pratica. MCP remoto self-hosted con autenticazione appropriata, hardening della sicurezza e supporto per sovereign cloud significa che MCP è pronto per team reali che costruiscono workflow agentici reali su Azure. Se stavi aspettando il segnale “enterprise-ready” — questo è.

.NET Aspire 13.2 Vuole Essere il Migliore Amico del Tuo Agente IA

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Conosci quel momento in cui il tuo agente IA scrive del codice solido, ti entusiasmi, e poi tutto crolla quando prova a eseguire la cosa? Conflitti di porte, processi fantasma, variabili d’ambiente sbagliate — improvvisamente il tuo agente sta bruciando token per risolvere problemi di avvio invece di costruire funzionalità.

Il team di Aspire ha appena pubblicato un post molto ben pensato su esattamente questo problema, e la loro risposta è convincente: Aspire 13.2 è progettato non solo per gli umani, ma per gli agenti IA.

Il problema è reale

Gli agenti IA sono incredibili nello scrivere codice. Ma consegnare un’app full-stack funzionante richiede molto di più che generare file. Devi avviare i servizi nell’ordine giusto, gestire le porte, impostare le variabili d’ambiente, connettere i database e ottenere feedback quando qualcosa si rompe. Al momento, la maggior parte degli agenti gestisce tutto questo per tentativi — eseguendo comandi, leggendo output di errore, riprovando.

Aggiungiamo istruzioni Markdown, skill personalizzati e prompt per guidarli, ma sono imprevedibili, non possono essere compilati e costano token solo per essere parsati. Il team di Aspire ha centrato l’insight chiave: gli agenti hanno bisogno di compilatori e API strutturate, non di più Markdown.

Aspire come infrastruttura per agenti

Ecco cosa porta Aspire 13.2 al tavolo dello sviluppo agentico:

Tutto il tuo stack in codice tipizzato. L’AppHost definisce la tua topologia completa — API, frontend, database, cache — in TypeScript o C# compilabile:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agente può leggere questo per capire la topologia dell’app, aggiungere risorse, collegare connessioni e compilare per verificare. Il compilatore gli dice immediatamente se qualcosa è sbagliato. Niente congetture, niente tentativi con i file di configurazione.

Un solo comando per governarli tutti. Invece di far destreggiate gli agenti tra docker compose up, npm run dev e script di avvio database, tutto è semplicemente aspire start. Tutte le risorse si avviano nell’ordine giusto, sulle porte giuste, con la configurazione giusta. I processi a lunga durata non bloccano l’agente — Aspire li gestisce.

Modalità isolata per agenti paralleli. Con --isolated, ogni esecuzione di Aspire ottiene le proprie porte casuali e segreti utente separati. Hai più agenti che lavorano su git worktree? Non entreranno in collisione. Questo è enorme per strumenti come gli agenti in background di VS Code che creano ambienti paralleli.

Occhi da agente attraverso la telemetria. Qui diventa davvero potente. La CLI di Aspire espone dati OpenTelemetry completi durante lo sviluppo — tracce, metriche, log strutturati. Il tuo agente non sta solo leggendo l’output della console sperando per il meglio. Può tracciare una richiesta fallita tra i servizi, profilare endpoint lenti e individuare esattamente dove le cose si rompono. Questa è osservabilità di livello produzione nel ciclo di sviluppo.

L’analogia dei parabordi del bowling

Il team di Aspire usa un’ottima analogia: pensa ad Aspire come ai parabordi della pista da bowling per gli agenti IA. Se l’agente non è perfetto (e non lo sarà), i parabordi impediscono che tiri nel canale. La definizione dello stack previene la misconfigurazioni, il compilatore cattura gli errori, la CLI gestisce i processi e la telemetria fornisce il ciclo di feedback.

Combina questo con qualcosa come Playwright CLI, e il tuo agente può davvero usare la tua app — cliccando nei flussi, controllando il DOM, vedendo le cose rotte nella telemetria, sistemando il codice, riavviando e testando di nuovo. Costruire, eseguire, osservare, sistemare. Questo è il ciclo di sviluppo autonomo che stavamo inseguendo.

Per iniziare

Nuovo con Aspire? Installa la CLI da get.aspire.dev e segui la guida introduttiva.

Già usi Aspire? Esegui aspire update --self per ottenere la 13.2, poi punta il tuo agente di coding preferito al tuo repo. Potresti stupirti di quanto va più lontano con i guardrail di Aspire.

Per concludere

Aspire 13.2 non è più solo un framework per app distribuite — sta diventando infrastruttura essenziale per agenti. Definizioni di stack strutturate, avvio con un comando, esecuzioni parallele isolate e telemetria in tempo reale danno agli agenti IA esattamente ciò di cui hanno bisogno per passare dallo scrivere codice al consegnare app.

Leggi il post completo dal team di Aspire per tutti i dettagli e i video dimostrativi.

Collega i tuoi server MCP su Azure Functions ai Foundry Agents — Ecco come

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Ecco cosa adoro dell’ecosistema MCP: costruisci il tuo server una volta e funziona ovunque. VS Code, Visual Studio, Cursor, ChatGPT — ogni client MCP può scoprire e utilizzare i tuoi strumenti. Ora, Microsoft sta aggiungendo un altro consumatore a quella lista: gli agenti Foundry.

Lily Ma del team Azure SDK ha pubblicato una guida pratica su come collegare server MCP distribuiti su Azure Functions con gli agenti Microsoft Foundry. Se hai già un server MCP, questo è puro valore aggiunto — nessuna ricostruzione necessaria.

Perché questa combinazione ha senso

Azure Functions ti offre infrastruttura scalabile, autenticazione integrata e fatturazione serverless per ospitare server MCP. Microsoft Foundry ti dà agenti AI che possono ragionare, pianificare e agire. Collegare i due significa che i tuoi strumenti personalizzati — interrogare un database, chiamare un’API aziendale, eseguire logica di validazione — diventano capacità che gli agenti AI aziendali possono scoprire e utilizzare autonomamente.

Il punto chiave: il tuo server MCP resta lo stesso. Stai semplicemente aggiungendo Foundry come un altro consumatore. Gli stessi strumenti che funzionano nel tuo setup VS Code ora alimentano un agente AI con cui il tuo team o i clienti interagiscono.

Opzioni di autenticazione

È qui che il post offre davvero valore. Quattro metodi di autenticazione a seconda del tuo scenario:

Metodo	Caso d’uso
Basato su chiave (predefinito)	Sviluppo o server senza autenticazione Entra
Microsoft Entra	Produzione con identità gestite
Passthrough identità OAuth	Produzione dove ogni utente si autentica individualmente
Senza autenticazione	Dev/test o solo dati pubblici

Per la produzione, Microsoft Entra con identità dell’agente è il percorso consigliato. Il passthrough identità OAuth è per quando il contesto utente conta — l’agente chiede agli utenti di accedere, e ogni richiesta porta il token personale dell’utente.

Configurazione

Il flusso generale:

Distribuisci il tuo server MCP su Azure Functions — esempi disponibili per .NET, Python, TypeScript e Java
Abilita l’autenticazione MCP integrata sulla tua function app
Ottieni l’URL del tuo endpoint — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Aggiungi il server MCP come strumento in Foundry — naviga al tuo agente nel portale, aggiungi un nuovo strumento MCP, fornisci endpoint e credenziali

Poi testalo nel playground dell’Agent Builder inviando un prompt che attiverebbe uno dei tuoi strumenti.

La mia opinione

La storia della composabilità qui sta diventando davvero forte. Costruisci il tuo server MCP una volta in .NET (o Python, TypeScript, Java), distribuiscilo su Azure Functions, e ogni client compatibile con MCP può usarlo — strumenti di codifica, app di chat, e ora agenti AI aziendali. È un pattern “scrivi una volta, usa ovunque” che funziona davvero.

Per gli sviluppatori .NET nello specifico, l’estensione MCP di Azure Functions rende tutto semplice. Definisci i tuoi strumenti come Azure Functions, fai il deploy, e hai un server MCP di livello produzione con tutta la sicurezza e la scalabilità che Azure Functions offre.

Conclusione

Se hai strumenti MCP in esecuzione su Azure Functions, collegarli agli agenti Foundry è una vittoria rapida — i tuoi strumenti personalizzati diventano capacità AI aziendali con autenticazione adeguata e senza modifiche al codice del server.

Leggi la guida completa per istruzioni passo passo su ogni metodo di autenticazione, e consulta la documentazione dettagliata per configurazioni di produzione.

La Modalità Isolata di Aspire Risolve l'Incubo dei Conflitti di Porta per lo Sviluppo Parallelo

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Se hai mai provato a eseguire due istanze dello stesso progetto contemporaneamente, conosci il dolore. La porta 8080 è già in uso. La porta 17370 è occupata. Uccidi qualcosa, riavvia, destreggiati tra le variabili d’ambiente — è un killer della produttività.

Questo problema sta peggiorando, non migliorando. Gli agenti IA creano git worktree per lavorare in modo indipendente. Gli agenti in background avviano ambienti separati. Gli sviluppatori fanno checkout dello stesso repo due volte per i feature branch. Ognuno di questi scenari sbatte contro lo stesso muro: due istanze della stessa app che lottano per le stesse porte.

Aspire 13.2 risolve questo con un singolo flag. James Newton-King del team Aspire ha scritto tutti i dettagli, ed è una di quelle feature “perché non l’avevamo già?”

La soluzione: `--isolated`

aspire run --isolated

Questo è tutto. Ogni esecuzione ottiene:

Porte random — niente più collisioni tra istanze
Segreti utente isolati — connection string e chiavi API restano separate per istanza

Nessuna riassegnazione manuale delle porte. Nessun giocoleria con le variabili d’ambiente. Ogni esecuzione ottiene un ambiente pulito e privo di collisioni automaticamente.

Scenari reali dove questo brilla

Checkout multipli. Hai un feature branch in una directory e un bugfix in un’altra:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Entrambi girano senza conflitti. La dashboard mostra cosa sta girando e dove.

Agenti in background in VS Code. Quando l’agente in background di Copilot Chat crea un git worktree per lavorare sul tuo codice in modo indipendente, potrebbe aver bisogno di eseguire il tuo AppHost Aspire. Senza --isolated, c’è un conflitto di porte con il tuo worktree principale. Con esso, entrambe le istanze funzionano e basta.

Lo skill Aspire distribuito con aspire agent init istruisce automaticamente gli agenti a usare --isolated quando lavorano nei worktree. Quindi l’agente in background di Copilot dovrebbe gestire tutto nativamente.

Test di integrazione in parallelo allo sviluppo. Hai bisogno di eseguire test contro un AppHost live mentre continui a sviluppare funzionalità? La modalità isolata dà a ogni contesto le sue porte e la sua configurazione.

Come funziona sotto il cofano

Quando passi --isolated, la CLI genera un ID di istanza unico per l’esecuzione. Questo guida due comportamenti:

Randomizzazione delle porte — invece di legarsi a porte prevedibili definite nella configurazione del tuo AppHost, la modalità isolata sceglie porte casuali disponibili per tutto — la dashboard, gli endpoint dei servizi, tutto. Il service discovery si adatta automaticamente, così i servizi si trovano a vicenda indipendentemente da quali porte ottengono.
Isolamento dei segreti — ogni esecuzione isolata ottiene il proprio store di segreti utente, identificato dall’ID dell’istanza. Connection string e chiavi API di un’esecuzione non trapelano in un’altra.

Il tuo codice non ha bisogno di modifiche. Il service discovery di Aspire risolve gli endpoint a runtime, quindi tutto si connette correttamente indipendentemente dall’assegnazione delle porte.

Quando usarlo

Usa --isolated quando esegui più istanze dello stesso AppHost contemporaneamente — che si tratti di sviluppo parallelo, test automatizzati, agenti IA o git worktree. Per lo sviluppo a singola istanza dove preferisci porte prevedibili, il normale aspire run funziona ancora benissimo.

Per concludere

La modalità isolata è una piccola feature che risolve un problema reale e sempre più comune. Man mano che lo sviluppo assistito da IA ci spinge verso più workflow paralleli — agenti multipli, worktree multipli, contesti multipli — la capacità di semplicemente avviare un’altra istanza senza lottare per le porte è essenziale.

Leggi il post completo per tutti i dettagli tecnici e provalo con aspire update --self per ottenere la 13.2.

La valutazione di modernizzazione di GitHub Copilot è il miglior strumento di migrazione che non stai ancora usando

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Migrare un’app legacy .NET Framework a .NET moderno è una di quelle attività che tutti sanno di dover fare ma che nessuno vuole iniziare. Non è mai solo “cambiare il target framework.” Sono API che sono scomparse, pacchetti che non esistono più, modelli di hosting che funzionano in modo completamente diverso, e un milione di piccole decisioni su cosa containerizzare, cosa riscrivere e cosa lasciare così.

Jeffrey Fritz ha appena pubblicato un approfondimento sulla valutazione di modernizzazione di GitHub Copilot, e onestamente? È il miglior tooling di migrazione che abbia visto per .NET. Non per la generazione di codice — quello è ormai standard. Per il documento di valutazione che produce.

Non è solo un motore di suggerimenti di codice

L’estensione VS Code segue un modello Valuta → Pianifica → Esegui. La fase di valutazione analizza l’intero codebase e produce un documento strutturato che cattura tutto: cosa deve cambiare, quali risorse Azure provisionare, quale modello di deployment usare. Tutto ciò che segue — infrastructure as code, containerizzazione, manifesti di deployment — deriva da ciò che la valutazione trova.

La valutazione viene salvata in .github/modernize/assessment/ nel tuo progetto. Ogni esecuzione produce un report indipendente, così accumuli uno storico e puoi monitorare come la tua postura di migrazione evolve man mano che risolvi gli issue.

Due modi per iniziare

Valutazione Consigliata — il percorso veloce. Scegli tra domini curati (Upgrade Java/.NET, Cloud Readiness, Sicurezza) e ottieni risultati significativi senza toccare la configurazione. Ottimo per un primo sguardo a dove si trova la tua app.

Valutazione Personalizzata — il percorso mirato. Configura esattamente cosa analizzare: compute target (App Service, AKS, Container Apps), OS target, analisi della containerizzazione. Scegli più target Azure per confrontare gli approcci di migrazione fianco a fianco.

Quella vista di confronto è genuinamente utile. Un’app con 3 issue obbligatori per App Service potrebbe averne 7 per AKS. Vedere entrambi aiuta a guidare la decisione sull’hosting prima di impegnarsi in un percorso di migrazione.

La suddivisione degli issue è azionabile

Ogni issue viene con un livello di criticità:

Obbligatorio — deve essere risolto o la migrazione fallisce
Potenziale — potrebbe impattare la migrazione, necessita di giudizio umano
Opzionale — miglioramenti raccomandati, non bloccano la migrazione

E ogni issue linka ai file interessati e numeri di riga, fornisce una descrizione dettagliata di cosa c’è che non va e perché conta per la tua piattaforma target, dà passaggi concreti di remediation (non solo “sistema questo”), e include link alla documentazione ufficiale.

Puoi assegnare singoli issue agli sviluppatori e hanno tutto ciò di cui hanno bisogno per agire. Questa è la differenza tra uno strumento che ti dice “c’è un problema” e uno che ti dice come risolverlo.

I percorsi di upgrade coperti

Per .NET specificamente:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Ogni percorso di upgrade ha regole di rilevamento che sanno quali API sono state rimosse, quali pattern non hanno un equivalente diretto e quali problemi di sicurezza richiedono attenzione.

Per i team che gestiscono più applicazioni, c’è anche un CLI che supporta valutazioni batch multi-repo — clona tutti i repo, valutali tutti, ottieni report per app più una vista aggregata del portfolio.

La mia opinione

Se sei seduto su applicazioni legacy .NET Framework (e siamo onesti, la maggior parte dei team enterprise lo è), questo è lo strumento con cui iniziare. Il solo documento di valutazione vale il tempo — trasforma un vago “dovremmo modernizzare” in una lista concreta e prioritizzata di elementi di lavoro con percorsi chiari in avanti.

Il workflow collaborativo è intelligente anche: esporta le valutazioni, condividile con il tuo team, importale senza rieseguire. Review di architettura dove chi decide non è chi esegue gli strumenti? Coperto.

Conclusione

La valutazione di modernizzazione di GitHub Copilot trasforma la migrazione .NET da un progetto spaventoso e indefinito in un processo strutturato e tracciabile. Inizia con una valutazione consigliata per vedere a che punto sei, poi usa valutazioni personalizzate per confrontare i target Azure e costruire il tuo piano di migrazione.

Leggi il walkthrough completo e scarica l’estensione VS Code per provarla sul tuo codebase.

Le MCP Apps hanno una Fluent API — Crea interfacce ricche per strumenti AI in .NET in tre passaggi

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Gli strumenti MCP sono fantastici per dare capacità agli agenti AI. Ma cosa succede se il tuo strumento deve mostrare qualcosa all’utente — una dashboard, un form, una visualizzazione interattiva? È qui che entrano in gioco le MCP Apps, e ora sono diventate molto più facili da costruire.

Lilian Kasem del team Azure SDK ha presentato la nuova API di configurazione fluent per le MCP Apps su Azure Functions .NET, ed è il tipo di miglioramento dell’esperienza sviluppatore che ti fa chiedere perché non fosse sempre così semplice.

Cosa sono le MCP Apps?

Le MCP Apps estendono il Model Context Protocol permettendo agli strumenti di portare le proprie viste UI, asset statici e controlli di sicurezza. Invece di restituire solo testo, il tuo strumento MCP può renderizzare esperienze HTML complete — dashboard interattive, visualizzazioni di dati, form di configurazione — tutto invocabile dagli agenti AI e presentato agli utenti dai client MCP.

Il problema era che collegare tutto manualmente richiedeva di conoscere la specifica MCP in profondità: URI ui://, tipi MIME speciali, coordinamento dei metadati tra strumenti e risorse. Non difficile, ma noioso.

La Fluent API in tre passaggi

Passaggio 1: Definisci la tua funzione. Uno strumento MCP standard di Azure Functions:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Passaggio 2: Promuovila a MCP App. Nello startup del tuo programma:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Passaggio 3: Aggiungi la tua vista HTML. Crea assets/hello-app.html con l’interfaccia di cui hai bisogno.

Tutto qui. La Fluent API gestisce tutta l’infrastruttura del protocollo MCP — genera la funzione risorsa sintetica, imposta il tipo MIME corretto e inietta i metadati che collegano il tuo strumento alla sua vista.

La superficie dell’API è ben progettata

Alcune cose che mi piacciono molto:

Le fonti delle viste sono flessibili. Puoi servire HTML da file su disco, o incorporare risorse direttamente nel tuo assembly per deployment autonomi:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

Il CSP è componibile. Autorizzi esplicitamente le origini di cui la tua app ha bisogno, seguendo i principi del minimo privilegio. Chiama WithCsp più volte e le origini si accumulano:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Controllo della visibilità. Puoi rendere uno strumento visibile solo al LLM, solo all’UI dell’host, o entrambi. Vuoi uno strumento che renderizza solo UI e non dovrebbe essere chiamato dal modello? Facile:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Per iniziare

Aggiungi il pacchetto preview:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Se stai già costruendo strumenti MCP con Azure Functions, è solo un aggiornamento del pacchetto. Il quickstart MCP Apps è il miglior punto di partenza se sei nuovo al concetto.

Conclusione

Le MCP Apps sono uno degli sviluppi più entusiasmanti nello spazio degli strumenti AI — strumenti che non solo fanno cose ma possono mostrare cose agli utenti. La Fluent API rimuove la complessità del protocollo e ti permette di concentrarti su ciò che conta: la logica del tuo strumento e la sua interfaccia.

Leggi il post completo per il riferimento completo dell’API e gli esempi.

C# 15 introduce i tipi union — e sono esattamente quello che stavamo chiedendo

Emiliano Montesdeoca — Sun, 05 Apr 2026 00:00:00 +0000

Questa è quella che stavo aspettando. C# 15 introduce la parola chiave union — vere unioni discriminate con pattern matching esaustivo imposto dal compilatore. Se hai mai invidiato le unioni discriminate di F# o gli enum di Rust, sai esattamente perché questo è importante.

Bill Wagner ha pubblicato l’approfondimento sul blog .NET, e onestamente? Il design è pulito, pratico e molto C#. Lascia che ti mostri cosa c’è davvero e perché è una cosa più grande di quanto possa sembrare a prima vista.

Il problema che le union risolvono

Prima di C# 15, restituire “uno tra diversi tipi possibili” da un metodo era sempre un compromesso:

object — nessun vincolo, nessun aiuto dal compilatore, casting difensivo ovunque
Interfacce marcatore — meglio, ma chiunque può implementarle. Il compilatore non può mai considerare l’insieme completo
Classi base astratte — stesso problema, in più i tipi hanno bisogno di un antenato comune

Nessuna di queste ti dà quello che vuoi veramente: un insieme chiuso di tipi dove il compilatore garantisce che hai gestito ogni caso. Questo è quello che fanno i tipi union.

La sintassi è di una semplicità elegante

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Una riga. Pet può contenere un Cat, un Dog o un Bird. Le conversioni implicite vengono generate automaticamente:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

Ed ecco la magia — il compilatore impone il matching esaustivo:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

Nessun discard _ necessario. Il compilatore sa che questo switch copre ogni caso possibile. Se successivamente aggiungi un quarto tipo alla union, ogni espressione switch che non lo gestisce produce un avviso. Casi mancanti rilevati al momento della compilazione, non a runtime.

Dove diventa pratico

L’esempio di Pet è carino, ma è qui che le union brillano davvero nel codice reale.

Risposte API che restituiscono forme diverse

public union ApiResult<T>(T, ApiError, ValidationFailure);

Ora ogni consumatore è obbligato a gestire successo, errore e fallimento di validazione. Niente più bug da “ho dimenticato di controllare il caso di errore”.

Valore singolo o collection

Il pattern OneOrMore<T> mostra come le union possono avere un corpo con metodi di utilità:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

I chiamanti passano la forma che preferiscono:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Comporre tipi non correlati

Questa è la funzionalità killer rispetto alle gerarchie tradizionali. Puoi unire tipi che non hanno nulla in comune — string e Exception, int e IEnumerable<T>. Nessun antenato comune necessario.

Union personalizzate per librerie esistenti

Ecco una scelta di design intelligente: qualsiasi classe o struct con un attributo [Union] viene riconosciuta come tipo union, purché segua il pattern di base (costruttori pubblici per i tipi di caso e una proprietà Value). Librerie come OneOf che già forniscono tipi simili alle union possono optare per il supporto del compilatore senza riscrivere i loro interni.

Per scenari sensibili alle performance con tipi di valore, le librerie possono implementare un pattern di accesso senza boxing con i metodi HasValue e TryGetValue.

Il quadro generale

I tipi union fanno parte di una storia più ampia di esaustività in arrivo in C#:

Tipi union — matching esaustivo su un insieme chiuso di tipi (disponibile ora in preview)
Gerarchie chiuse — il modificatore closed impedisce classi derivate al di fuori dell’assembly di definizione (proposto)
Enum chiusi — impedisce la creazione di valori diversi dai membri dichiarati (proposto)

Insieme, queste tre funzionalità daranno a C# uno dei sistemi di pattern matching type-safe più completi in qualsiasi linguaggio mainstream.

Provale oggi

I tipi union sono disponibili in .NET 11 Preview 2:

Installa il SDK .NET 11 Preview
Imposta come target net11.0 nel tuo progetto
Imposta <LangVersion>preview</LangVersion>

Un’avvertenza: in Preview 2, dovrai dichiarare UnionAttribute e IUnion nel tuo progetto poiché non sono ancora nel runtime. Prendi RuntimePolyfill.cs dal repo docs, o aggiungi questo:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Per concludere

I tipi union sono una di quelle funzionalità che ti fanno chiedere come abbiamo fatto senza. Pattern matching esaustivo imposto dal compilatore, sintassi pulita, supporto ai generici e integrazione con il pattern matching esistente — è tutto quello che abbiamo chiesto, fatto alla maniera C#.

Provale in .NET 11 Preview 2, rompi cose e condividi il tuo feedback su GitHub. Questa è una preview, e il team C# sta attivamente ascoltando. I tuoi edge case e feedback di design daranno forma alla release finale.

Per il riferimento completo del linguaggio, consulta la documentazione dei tipi union e la specifica della funzionalità.

Aspire 13.2 include una CLI per la documentazione — e anche il tuo agente IA può usarla

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

Conosci quel momento in cui sei immerso in un Aspire AppHost, stai collegando integrazioni, e devi controllare esattamente quali parametri si aspetta l’integrazione Redis? Fai alt-tab al browser, cerchi su aspire.dev, strizzi gli occhi sulla documentazione delle API, poi torni al tuo editor. Contesto perso. Flusso interrotto.

Aspire 13.2 ha appena rilasciato una soluzione per questo. La CLI aspire docs ti permette di cercare, esplorare e leggere la documentazione ufficiale di Aspire direttamente dal tuo terminale. E siccome è supportata da servizi riutilizzabili, gli agenti IA e le skill possono usare gli stessi comandi per consultare la documentazione invece di allucinare API che non esistono.

Il problema che questo risolve davvero

David Pine lo dice perfettamente nel post originale: gli agenti IA erano terribili nell’aiutare gli sviluppatori a costruire app con Aspire. Raccomandavano dotnet run invece di aspire run, facevano riferimento a learn.microsoft.com per docs che vivono su aspire.dev, suggerivano pacchetti NuGet obsoleti, e — il mio preferito — allucinavano API inesistenti.

Perché? Perché Aspire è stato specifico per .NET molto più a lungo di quanto sia stato poliglotta, e i LLM lavorano con dati di addestramento che precedono le ultime funzionalità. Quando dai a un agente IA la possibilità di consultare la documentazione attuale, smette di tirare a indovinare e inizia a essere utile.

Tre comandi, zero schede del browser

La CLI è di una semplicità rinfrescante:

Elencare tutta la documentazione

aspire docs list

Restituisce ogni pagina di documentazione disponibile su aspire.dev. Serve un output leggibile dalle macchine? Aggiungi --format Json.

Cercare un argomento

aspire docs search "redis"

Cerca sia nei titoli che nei contenuti con punteggio di rilevanza ponderato. Lo stesso motore di ricerca che alimenta internamente gli strumenti di documentazione. Ottieni risultati classificati con titoli, slug e punteggi di rilevanza.

Leggere una pagina intera (o solo una sezione)

aspire docs get redis-integration

Trasmette la pagina completa in markdown nel tuo terminale. Ti serve solo una sezione?

aspire docs get redis-integration --section "Add Redis resource"

Precisione chirurgica. Niente scrolling su 500 righe. Solo la parte che ti serve.

L’aspetto agente IA

Ecco dove diventa interessante per noi sviluppatori che costruiamo con strumenti IA. Gli stessi comandi aspire docs funzionano come strumenti per agenti IA — tramite skill, server MCP, o semplici wrapper CLI.

Invece di far inventare al tuo assistente IA delle API Aspire basate su dati di addestramento obsoleti, può chiamare aspire docs search "postgres", trovare la documentazione ufficiale dell’integrazione, leggere la pagina giusta, e darti l’approccio documentato. Documentazione in tempo reale e aggiornata — non quello che il modello ha memorizzato sei mesi fa.

L’architettura dietro tutto questo è intenzionale. Il team Aspire ha costruito servizi riutilizzabili (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) anziché un’integrazione una tantum. Questo significa che lo stesso motore di ricerca funziona per gli umani nel terminale, gli agenti IA nel tuo editor, e l’automazione nella tua pipeline CI.

Scenari reali

Consultazioni rapide nel terminale: Sei tre file in profondità e hai bisogno dei parametri di configurazione Redis. Due comandi, novanta secondi, di nuovo al lavoro:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Sviluppo assistito dall’IA: La tua skill di VS Code avvolge i comandi CLI. Chiedi “Aggiungi un database PostgreSQL al mio AppHost” e l’agente consulta i docs reali prima di rispondere. Nessuna allucinazione.

Validazione CI/CD: La tua pipeline valida le configurazioni AppHost contro la documentazione ufficiale in modo programmatico. L’output --format Json si collega in modo pulito a jq e altri strumenti.

Basi di conoscenza personalizzate: Stai costruendo i tuoi strumenti IA? Invia l’output JSON strutturato direttamente nella tua base di conoscenza:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Niente web scraping. Niente chiavi API. Gli stessi dati strutturati usati internamente dagli strumenti di documentazione.

La documentazione è sempre aggiornata

Questa è la parte che apprezzo di più. La CLI non scarica uno snapshot — interroga aspire.dev con caching basato su ETag. Nel momento in cui la documentazione viene aggiornata, la tua CLI e qualsiasi skill costruita su di essa lo riflette. Niente copie obsolete, niente momenti “ma il wiki diceva…”.

Per concludere

aspire docs è una di quelle piccole funzionalità che risolve un problema reale in modo pulito. Gli umani ottengono accesso alla documentazione nativo nel terminale. Gli agenti IA ottengono un modo per smettere di indovinare e iniziare a fare riferimento a docs reali. E tutto è supportato dalla stessa fonte di verità.

Se stai costruendo con .NET Aspire e non hai ancora provato la CLI, esegui aspire docs search "il-tuo-argomento-qui" e vedi come ti sembra. Poi considera di integrare quei comandi nella skill IA o nella configurazione di automazione che stai usando — i tuoi agenti ti ringrazieranno.

Dai un’occhiata all’approfondimento di David Pine su come sono nati gli strumenti di documentazione, e al riferimento ufficiale della CLI per tutti i dettagli.

Microsoft Agent Framework Raggiunge la 1.0 — Ecco Cosa Conta Davvero per gli Sviluppatori .NET

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

Se hai seguito il percorso di Agent Framework dai primi giorni di Semantic Kernel e AutoGen, questo è significativo. Microsoft Agent Framework ha appena raggiunto la versione 1.0 — pronto per la produzione, API stabili, impegno di supporto a lungo termine. È disponibile sia per .NET che per Python, ed è genuinamente pronto per carichi di lavoro reali.

Vi taglio attraverso il rumore dell’annuncio e mi concentro su ciò che conta se state costruendo app alimentate dall’IA con .NET.

La versione breve

Agent Framework 1.0 unifica quello che erano Semantic Kernel e AutoGen in un singolo SDK open source. Un’astrazione di agente. Un motore di orchestrazione. Molteplici provider di IA. Se avete saltato tra Semantic Kernel per i pattern enterprise e AutoGen per i workflow multi-agente di livello ricerca, potete smettere. Questo è l’unico SDK ora.

Iniziare è quasi ingiustamente semplice

Ecco un agente funzionante in .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Tutto qui. Una manciata di righe e hai un agente IA che gira su Azure Foundry. L’equivalente Python è altrettanto conciso. Aggiungi strumenti di funzione, conversazioni multi-turno e streaming man mano che procedi — la superficie dell’API scala senza diventare strana.

Orchestrazione multi-agente — questa è la cosa seria

Gli agenti singoli vanno bene per le demo, ma gli scenari di produzione di solito necessitano di coordinamento. Agent Framework 1.0 arriva con pattern di orchestrazione testati in battaglia direttamente da Microsoft Research e AutoGen:

Sequenziale — gli agenti elaborano in ordine (scrittore → revisore → editor)
Concorrente — distribuisci a più agenti in parallelo, convergi i risultati
Handoff — un agente delega a un altro in base all’intento
Chat di gruppo — più agenti discutono e convergono su una soluzione
Magentic-One — il pattern multi-agente di livello ricerca di MSR

Tutti supportano streaming, checkpointing, approvazioni human-in-the-loop e pausa/ripresa. La parte di checkpointing è cruciale — i workflow di lunga durata sopravvivono ai riavvii del processo. Per noi sviluppatori .NET che abbiamo costruito workflow durevoli con Azure Functions, questo è familiare.

Le funzionalità che contano di più

Ecco la mia lista di ciò che vale la pena sapere:

Hook middleware. Sapete come ASP.NET Core ha le pipeline middleware? Stesso concetto, ma per l’esecuzione degli agenti. Intercetta ogni fase — aggiungi sicurezza dei contenuti, logging, policy di conformità — senza toccare i prompt dell’agente. È così che rendi gli agenti pronti per l’enterprise.

Memoria pluggable. Storico conversazionale, stato persistente chiave-valore, recupero basato su vettori. Scegli il tuo backend: Foundry Agent Service, Mem0, Redis, Neo4j, o costruisci il tuo. La memoria è ciò che trasforma una chiamata LLM senza stato in un agente che ricorda davvero il contesto.

Agenti YAML dichiarativi. Definisci le istruzioni del tuo agente, gli strumenti, la memoria e la topologia di orchestrazione in file YAML versionati. Carica ed esegui con una singola chiamata API. Questo è un game-changer per i team che vogliono iterare sul comportamento dell’agente senza ridistribuire il codice.

Supporto A2A e MCP. MCP (Model Context Protocol) permette agli agenti di scoprire e invocare strumenti esterni dinamicamente. A2A (protocollo Agent-to-Agent) abilita la collaborazione cross-runtime — i tuoi agenti .NET possono coordinarsi con agenti in esecuzione in altri framework. Il supporto A2A 1.0 arriverà presto.

Le funzionalità in preview da tenere d’occhio

Alcune funzionalità sono state rilasciate come preview nella 1.0 — funzionali ma le API potrebbero evolvere:

DevUI — un debugger locale basato su browser per visualizzare l’esecuzione dell’agente, i flussi di messaggi e le chiamate agli strumenti in tempo reale. Pensate ad Application Insights, ma per il ragionamento dell’agente.
GitHub Copilot SDK e Claude Code SDK — usa Copilot o Claude come harness dell’agente direttamente dal tuo codice di orchestrazione. Componi un agente capace di programmare accanto ai tuoi altri agenti nello stesso workflow.
Agent Harness — un runtime locale personalizzabile che dà agli agenti accesso a shell, file system e loop di messaggistica. Pensate ad agenti di coding e pattern di automazione.
Skills — pacchetti riutilizzabili di capacità di dominio che danno agli agenti capacità strutturate pronte all’uso.

Migrazione da Semantic Kernel o AutoGen

Se avete codice Semantic Kernel o AutoGen esistente, ci sono assistenti di migrazione dedicati che analizzano il vostro codice e generano piani di migrazione passo dopo passo. La guida alla migrazione da Semantic Kernel e la guida alla migrazione da AutoGen vi accompagnano attraverso tutto.

Se siete stati sui pacchetti RC, l’aggiornamento alla 1.0 è solo un cambio di versione.

Per concludere

Agent Framework 1.0 è il traguardo di produzione che i team enterprise stavano aspettando. API stabili, supporto multi-provider, pattern di orchestrazione che funzionano davvero su scala, e percorsi di migrazione sia da Semantic Kernel che da AutoGen.

Il framework è completamente open source su GitHub, e potete iniziare oggi con dotnet add package Microsoft.Agents.AI. Date un’occhiata alla guida rapida e agli esempi per mettere le mani in pasta.

Se stavate aspettando il segnale “sicuro da usare in produzione” — eccolo.

azd ora permette di eseguire e debuggare agenti IA localmente — Ecco cosa è cambiato a marzo 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Sette rilasci in un mese. È quello che il team dell’Azure Developer CLI (azd) ha pubblicato a marzo 2026, e la funzionalità principale è quella che stavo aspettando: un loop locale di esecuzione e debug per agenti IA.

PC Chan ha pubblicato il riepilogo completo, e anche se c’è molto contenuto, lasciatemi filtrare ciò che conta davvero per gli sviluppatori .NET che costruiscono app con IA.

Eseguire e debuggare agenti IA senza deploy

Questa è la novità principale. La nuova estensione azure.ai.agents aggiunge comandi che danno un’esperienza di inner-loop adeguata per gli agenti IA:

azd ai agent run — avvia il tuo agente localmente
azd ai agent invoke — gli invia messaggi (locale o in produzione)
azd ai agent show — mostra lo stato del container e la sua salute
azd ai agent monitor — trasmette i log del container in tempo reale

Prima, testare un agente IA significava fare deploy su Microsoft Foundry ogni volta che facevi un cambiamento. Ora puoi iterare localmente, testare il comportamento del tuo agente, e fare deploy solo quando sei pronto.

GitHub Copilot configura il tuo progetto azd

azd init ora offre un’opzione “Set up with GitHub Copilot (Preview)”. Invece di rispondere manualmente ai prompt, un agente Copilot genera la configurazione per te. Quando un comando fallisce, azd offre troubleshooting assistito dall’IA — tutto senza lasciare il terminale.

Container App Jobs e miglioramenti del deployment

Container App Jobs: azd ora fa deploy di Microsoft.App/jobs tramite la config esistente host: containerapp.
Timeout configurabili: Nuovo flag --timeout su azd deploy e campo deployTimeout in azure.yaml.
Fallback di build remoto: Quando il build ACR fallisce, azd passa automaticamente a Docker/Podman locale.
Validazione preflight locale: I parametri Bicep vengono validati localmente prima del deploy.

Miglioramenti DX

Rilevamento automatico pnpm/yarn per progetti JS/TS
Supporto pyproject.toml per Python
Directory template locali — azd init --template accetta percorsi del filesystem
Messaggi di errore migliori in modalità --no-prompt
Variabili d’ambiente di build iniettate in tutti i sottoprocessi di build (.NET, Node.js, Java, Python)

Per concludere

Il loop locale di debug per agenti IA è la star di questa release, ma l’accumulo di miglioramenti al deployment e alla DX rende azd più maturo che mai. Se fai deploy di app .NET su Azure — specialmente agenti IA — questo aggiornamento vale la pena.

Consulta le note di rilascio complete per tutti i dettagli.

L'aggiornamento di marzo di Visual Studio permette di creare agenti Copilot personalizzati — e find_symbol è rivoluzionario

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Visual Studio ha appena ricevuto il suo aggiornamento Copilot più significativo. Mark Downie ha annunciato il rilascio di marzo, e il titolo sono gli agenti personalizzati — ma onestamente, lo strumento find_symbol potrebbe essere la funzionalità che cambia di più il tuo workflow.

Agenti Copilot personalizzati nel tuo repo

Vuoi che Copilot segua gli standard del tuo team? Gli agenti personalizzati sono definiti come file .agent.md in .github/agents/. Ogni agente ha accesso completo al workspace, comprensione del codice, strumenti, il tuo modello preferito e connessioni MCP.

Agent skill: pacchetti di istruzioni riutilizzabili

Le skill vengono caricate automaticamente da .github/skills/ nel tuo repo o ~/.copilot/skills/ nel tuo profilo.

find_symbol: navigazione consapevole del linguaggio

Il nuovo strumento find_symbol dà alla modalità agente di Copilot una navigazione dei simboli basata sui servizi di linguaggio. Invece di cercare testo, l’agente può trovare tutti i riferimenti di un simbolo e accedere a informazioni su tipi e scope.

Per gli sviluppatori .NET, è un miglioramento enorme — i codebase C# con gerarchie di tipi profonde ne beneficiano enormemente.

Profilare test con Copilot

C’è un nuovo Profile with Copilot nel menu contestuale del Test Explorer. Il Profiling Agent esegue il test e analizza le performance automaticamente.

Perf tip durante il debug dal vivo

L’ottimizzazione delle performance ora avviene durante il debug. Visual Studio mostra il tempo di esecuzione inline. Linea lenta? Clicca sul Perf Tip e chiedi a Copilot suggerimenti.

Correggere vulnerabilità NuGet dal Solution Explorer

Un link Fix with GitHub Copilot appare direttamente nel Solution Explorer quando viene rilevata una vulnerabilità.

Per concludere

Agenti personalizzati e skill fanno il titolo, ma find_symbol è la gemma nascosta — cambia fondamentalmente la precisione di Copilot nel refactoring di codice .NET. Scarica Visual Studio 2026 Insiders per provare tutto.

La Dashboard di Aspire 13.2 ora ha un'API di telemetria — e cambia tutto

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Se hai sviluppato applicazioni distribuite con .NET Aspire, sai già che la dashboard è la cosa migliore dell’intera esperienza. Tutti i tuoi trace, log e metriche in un unico posto — niente Jaeger esterno, niente configurazione di Seq, niente momenti “fammi controllare l’altro terminale”.

Aspire 13.2 ha appena migliorato tutto significativamente. James Newton-King ha annunciato l’aggiornamento, e onestamente? Le funzionalità di esportazione telemetria e l’API da sole giustificano l’upgrade.

Esportare telemetria come una persona normale

Ecco lo scenario che abbiamo vissuto tutti: stai debuggando un problema distribuito, finalmente lo riproduci dopo venti minuti di setup, e ora devi condividere con il team quello che è successo. Prima? Screenshot. Copia e incolla degli ID delle trace. Il solito caos.

Aspire 13.2 aggiunge un dialog Gestisci log e telemetria dove puoi:

Pulire tutta la telemetria (utile prima di un tentativo di riproduzione)
Esportare telemetria selezionata in un file ZIP nel formato standard OTLP/JSON
Re-importare quel ZIP in qualsiasi dashboard Aspire successivamente

Quest’ultimo punto è la funzionalità killer. Riproduci un bug, esporti la telemetria, la alleghi al tuo work item, e il tuo collega può importarla nella propria dashboard per vedere esattamente quello che hai visto tu. Niente più “riesci a riprodurlo sulla tua macchina?”

Trace, span e log individuali hanno anche un’opzione “Export JSON” nei menu contestuali. Devi condividere una trace specifica? Click destro, copia JSON, incolla nella descrizione della PR. Fatto.

L’API di telemetria è il vero punto di svolta

Questo è ciò che mi entusiasma di più. La dashboard ora espone un’API HTTP sotto /api/telemetry per interrogare i dati di telemetria programmaticamente. Endpoint disponibili:

GET /api/telemetry/resources — elencare risorse con telemetria
GET /api/telemetry/spans — interrogare span con filtri
GET /api/telemetry/logs — interrogare log con filtri
GET /api/telemetry/traces — elencare trace
GET /api/telemetry/traces/{traceId} — ottenere tutti gli span per una trace specifica

Tutto torna in formato OTLP JSON. Questo alimenta i nuovi comandi CLI aspire agent mcp e aspire otel, ma l’implicazione reale è più grande: ora puoi costruire strumenti, script e integrazioni con agenti IA che interrogano direttamente la telemetria della tua app.

Immagina un agente IA che può vedere le tue trace distribuite reali durante il debug. Non è più ipotetico — è ciò che questa API rende possibile.

La telemetria GenAI diventa pratica

Se stai costruendo app con IA usando Semantic Kernel o Microsoft.Extensions.AI, apprezzerai il visualizzatore di telemetria GenAI migliorato. Aspire 13.2 aggiunge:

Descrizioni degli strumenti IA renderizzate come Markdown
Un pulsante GenAI dedicato nella pagina delle trace per accesso rapido
Migliore gestione errori per JSON GenAI troncato o non standard
Navigazione click-to-highlight tra le definizioni degli strumenti

Il post menziona che VS Code Copilot chat, Copilot CLI e OpenCode supportano tutti la configurazione di un OTEL_EXPORTER_OTLP_ENDPOINT. Puntali alla dashboard Aspire e puoi letteralmente guardare i tuoi agenti IA pensare in tempo reale attraverso la telemetria. Questa è un’esperienza di debug che non troverai da nessun’altra parte.

Per concludere

Aspire 13.2 trasforma la dashboard da “bella UI di debug” a “piattaforma di osservabilità programmabile”. Il flusso di esportazione/importazione da solo fa risparmiare tempo reale nel debug distribuito, e l’API di telemetria apre la porta alla diagnostica assistita dall’IA.

Se sei già su Aspire, aggiorna. Se no — questa è una buona ragione per dare un’occhiata a aspire.dev.

KubeCon Europe 2026: Cosa dovrebbero davvero sapere gli sviluppatori .NET

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Questo post è stato tradotto automaticamente. Per la versione originale, clicca qui.

Conosci quella sensazione quando esce un post di annunci enorme e scrolli pensando “bello, ma cosa cambia davvero per me”? Mi succede ogni stagione KubeCon.

Microsoft ha appena pubblicato il riassunto completo di KubeCon Europe 2026 — scritto da Brendan Burns in persona — e onestamente? C’è sostanza vera. Non solo checklist di feature, ma miglioramenti operativi che cambiano come gestisci le cose in produzione.

Vediamo cosa conta davvero per noi sviluppatori .NET.

mTLS senza la tassa del service mesh

Il punto sui service mesh: tutti vogliono le garanzie di sicurezza, nessuno vuole il carico operativo. AKS sta finalmente colmando questo divario.

Azure Kubernetes Application Network ti dà mutual TLS, autorizzazione application-aware e telemetria del traffico — senza deployare un mesh pesante con sidecar. Combinato con Cilium mTLS in Advanced Container Networking Services, ottieni comunicazione crittografata pod-a-pod usando certificati X.509 e SPIRE per la gestione delle identità.

Cosa significa in pratica: le tue API ASP.NET Core che parlano con worker in background, i tuoi servizi gRPC che si chiamano a vicenda — tutto crittografato e verificato a livello di rete, senza modifiche al codice applicativo. È enorme.

Per i team che migrano da ingress-nginx, c’è anche Application Routing con Meshless Istio con supporto completo per Kubernetes Gateway API. Niente sidecar. Basato su standard. E hanno rilasciato strumenti ingress2gateway per la migrazione incrementale.

Osservabilità GPU che non è un ripensamento

Se stai eseguendo inferenza IA accanto ai tuoi servizi .NET (e siamo onesti, chi non sta iniziando?), probabilmente hai incontrato il punto cieco del monitoraggio GPU. Avevi dashboard fantastiche per CPU/memoria e poi… niente per le GPU senza configurazione manuale degli exporter.

AKS ora espone le metriche GPU nativamente in Prometheus e Grafana gestiti. Stesso stack, stesse dashboard, stessa pipeline di alerting. Nessun exporter custom, nessun agent di terze parti.

Sul lato rete, hanno aggiunto visibilità per flusso per traffico HTTP, gRPC e Kafka con un’esperienza Azure Monitor one-click. IP, porte, workload, direzione del flusso, decisioni di policy — tutto in dashboard integrate.

E quella che mi ha fatto guardare due volte: agentic container networking aggiunge un’interfaccia web dove puoi fare domande in linguaggio naturale sullo stato di rete del tuo cluster. “Perché il pod X non raggiunge il servizio Y?” → diagnostica read-only dalla telemetria live. Genuinamente utile alle 2 di notte.

Networking cross-cluster senza bisogno di un dottorato

Il multi-cluster Kubernetes storicamente è stato un’esperienza “porta la tua colla di rete”. Azure Kubernetes Fleet Manager ora offre networking cross-cluster tramite Cilium cluster mesh gestito:

Connettività unificata tra cluster AKS
Registro globale dei servizi per la scoperta cross-cluster
Configurazione gestita centralmente, non ripetuta per cluster

Se esegui microservizi .NET su più regioni per resilienza o compliance, questo sostituisce molto collante custom fragile. Il Servizio A in West Europe può scoprire e chiamare il Servizio B in East US attraverso il mesh, con policy di routing e sicurezza consistenti.

Aggiornamenti che non richiedono coraggio

Siamo onesti — gli aggiornamenti Kubernetes in produzione sono stressanti. “Aggiornare e sperare” è stata la strategia de facto per troppi team, ed è la ragione principale per cui i cluster restano indietro con le versioni.

Due nuove capacità cambiano questo:

Blue-green agent pool upgrade creano un pool di nodi parallelo con la nuova configurazione. Valida il comportamento, sposta il traffico gradualmente e mantieni un percorso di rollback pulito. Niente più mutazioni in-place su nodi di produzione.

Agent pool rollback permette di riportare un pool di nodi alla versione Kubernetes e all’immagine nodo precedenti dopo che un aggiornamento va storto — senza ricostruire il cluster.

Insieme, danno finalmente agli operatori un vero controllo sul ciclo di vita degli aggiornamenti. Per i team .NET, questo è importante perché la velocità della piattaforma controlla direttamente quanto rapidamente puoi adottare nuovi runtime, patch di sicurezza e capacità di rete.

I workload IA diventano cittadini di prima classe in Kubernetes

Il lavoro upstream open-source è altrettanto importante. Dynamic Resource Allocation (DRA) è appena andato in GA in Kubernetes 1.36, rendendo lo scheduling GPU una feature di prima classe invece di un workaround.

Alcuni progetti da tenere d’occhio:

Progetto	Cosa fa
AI Runway	API Kubernetes comune per l’inferenza — deploy di modelli senza conoscere K8s, con scoperta HuggingFace e stime dei costi
HolmesGPT	Troubleshooting agentico per il cloud-native — ora un progetto CNCF Sandbox
Dalec	Build dichiarativi di immagini container con generazione SBOM — meno CVE nella fase di build

La direzione è chiara: la tua API .NET, il tuo layer di orchestrazione con Semantic Kernel e i tuoi workload di inferenza dovrebbero tutti girare su un modello di piattaforma consistente. Ci stiamo arrivando.

Da dove partirei questa settimana

Se stai valutando questi cambiamenti per il tuo team, ecco la mia lista onesta di priorità:

Osservabilità prima — abilita le metriche GPU e i log di flusso di rete in un cluster non-prod. Guarda cosa ti sei perso.
Prova i blue-green upgrade — testa il workflow di rollback prima del tuo prossimo aggiornamento di cluster in produzione. Costruisci fiducia nel processo.
Pilota il networking identity-aware — scegli un percorso di servizio interno e abilita mTLS con Cilium. Misura l’overhead (spoiler: è minimo).
Valuta Fleet Manager — se gestisci più di due cluster, il networking cross-cluster si ripaga da solo in riduzione di collante custom.

Piccoli esperimenti, feedback veloce. È sempre la mossa giusta.

Per concludere

Gli annunci KubeCon possono essere travolgenti, ma questa tornata muove davvero l’ago per i team .NET su AKS. Migliore sicurezza di rete senza overhead di mesh, vera osservabilità GPU, aggiornamenti più sicuri e fondamenta più solide per l’infrastruttura IA.

Se sei già su AKS, è un ottimo momento per rafforzare la tua baseline operativa. E se stai pianificando di spostare workload .NET su Kubernetes — la piattaforma è appena diventata significativamente più pronta per la produzione.

Foundry Agent Service è GA: Cosa conta davvero per chi costruisce agenti .NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Siamo onesti — costruire un prototipo di agente IA è la parte facile. La parte difficile è tutto quello che viene dopo: metterlo in produzione con un adeguato isolamento di rete, eseguire valutazioni che significhino davvero qualcosa, gestire i requisiti di conformità e non rompere nulla alle 2 di notte.

Il Foundry Agent Service è appena andato in GA, e questo rilascio è focalizzato come un laser su quel gap del “tutto quello che viene dopo”.

Costruito sulla Responses API

Il titolo: il Foundry Agent Service di nuova generazione è costruito sulla OpenAI Responses API. Se stai già costruendo con quel wire protocol, migrare a Foundry richiede modifiche minime al codice. Cosa guadagni: sicurezza enterprise, networking privato, RBAC Entra, tracing completo e valutazione — sopra la tua logica di agente esistente.

L’architettura è intenzionalmente aperta. Non sei vincolato a un provider di modelli o a un framework di orchestrazione. Usa DeepSeek per la pianificazione, OpenAI per la generazione, LangGraph per l’orchestrazione — il runtime gestisce il livello di consistenza.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Networking privato: il bloccante enterprise rimosso

Questa è la funzionalità che sblocca l’adozione enterprise. Foundry ora supporta networking privato completo end-to-end con BYO VNet:

Nessun egress pubblico — il traffico dell’agente non tocca mai internet pubblico
Iniezione di container/subnet nella tua rete per comunicazione locale
Connettività degli strumenti inclusa — server MCP, Azure AI Search, agenti dati Fabric operano tutti su percorsi privati

L’ultimo punto è critico. Non sono solo le chiamate di inferenza a restare private — ogni invocazione di strumento e chiamata di retrieval resta anch’essa all’interno del perimetro della tua rete. Per i team che operano sotto policy di classificazione dei dati che vietano il routing esterno, questo era ciò che mancava.

Autenticazione MCP fatta bene

Le connessioni ai server MCP ora supportano l’intero spettro di pattern di autenticazione:

Metodo di auth	Quando usarlo
Basato su chiave	Accesso condiviso semplice per strumenti interni all’organizzazione
Entra Agent Identity	Servizio a servizio; l’agente si autentica come se stesso
Entra Managed Identity	Isolamento per progetto; nessuna gestione delle credenziali
OAuth Identity Passthrough	Accesso delegato dall’utente; l’agente agisce per conto degli utenti

OAuth Identity Passthrough è quello interessante. Quando gli utenti devono concedere a un agente l’accesso ai propri dati personali — il loro OneDrive, la loro organizzazione Salesforce, un’API SaaS con scope per utente — l’agente agisce per loro conto con flussi OAuth standard. Nessuna identità di sistema condivisa che finge di essere tutti.

Voice Live: voce a voce senza l’idraulica

Aggiungere la voce a un agente significava unire STT, LLM e TTS — tre servizi, tre hop di latenza, tre superfici di fatturazione, tutto sincronizzato a mano. Voice Live collassa tutto in una singola API gestita con:

Rilevamento semantico dell’attività vocale e del fine turno (capisce il significato, non solo il silenzio)
Soppressione del rumore e cancellazione dell’eco lato server
Supporto barge-in (gli utenti possono interrompere a metà risposta)

Le interazioni vocali passano attraverso lo stesso runtime dell’agente del testo. Stessi valutatori, stesse tracce, stessa visibilità dei costi. Per supporto clienti, servizio sul campo o scenari di accessibilità, questo sostituisce ciò che prima richiedeva una pipeline audio personalizzata.

Valutazioni: da checkbox a monitoraggio continuo

Qui è dove Foundry diventa serio sulla qualità in produzione. Il sistema di valutazione ora ha tre livelli:

Valutatori pronti all’uso — coerenza, rilevanza, fondatezza, qualità del retrieval, sicurezza. Connetti a un dataset o al traffico live e ottieni punteggi.
Valutatori personalizzati — codifica la tua logica di business, standard di tono e regole di conformità specifiche del dominio.
Valutazione continua — Foundry campiona il traffico di produzione live, esegue la tua suite di valutatori e mostra i risultati nei dashboard. Imposta alert di Azure Monitor per quando la fondatezza cala o le soglie di sicurezza vengono superate.

Tutto viene pubblicato in Azure Monitor Application Insights. Qualità dell’agente, salute dell’infrastruttura, costi e telemetria dell’applicazione — tutto in un unico posto.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Sei nuove regioni per agenti ospitati

Gli agenti ospitati sono ora disponibili in East US, North Central US, Sweden Central, Southeast Asia, Japan East e altre. Questo conta per i requisiti di residenza dei dati e per comprimere la latenza quando il tuo agente gira vicino alle sue fonti dati.

Perché è importante per gli sviluppatori .NET

Anche se gli esempi di codice nell’annuncio GA sono Python-first, l’infrastruttura sottostante è language-agnostic — e l’SDK .NET per azure-ai-projects segue gli stessi pattern. La Responses API, il framework di valutazione, il networking privato, l’auth MCP — tutto questo è disponibile da .NET.

Se stavi aspettando che gli agenti IA passassero da “demo cool” a “posso davvero consegnare questo al lavoro”, questo rilascio GA è il segnale. Networking privato, autenticazione adeguata, valutazione continua e monitoraggio di produzione sono i pezzi che mancavano.

Per concludere

Foundry Agent Service è disponibile ora. Installa l’SDK, apri il portale e inizia a costruire. La guida quickstart ti porta da zero a un agente funzionante in pochi minuti.

Per il deep-dive tecnico completo con tutti gli esempi di codice, consulta l’annuncio GA.

Risposte in background nel Microsoft Agent Framework: basta ansia da timeout

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Se hai costruito qualcosa con modelli di ragionamento come o3 o GPT-5.2, conosci il dolore. Il tuo agente inizia a ragionare su un compito complesso, il client resta in attesa, e da qualche parte tra “va tutto bene” e “si sarà bloccato?” la tua connessione va in timeout. Tutto quel lavoro? Perso.

Microsoft Agent Framework ha appena rilasciato le risposte in background — e onestamente, questa è una di quelle funzionalità che avrebbero dovuto esistere dal primo giorno.

Il problema con le chiamate bloccanti

In un pattern tradizionale richiesta-risposta, il tuo client si blocca finché l’agente non finisce. Funziona bene per i compiti veloci. Ma quando chiedi a un modello di ragionamento di fare ricerca approfondita, analisi multi-step, o generare un report di 20 pagine? Stai guardando minuti di tempo reale. Durante quella finestra:

Le connessioni HTTP possono scadere
I problemi di rete uccidono l’intera operazione
Il tuo utente fissa uno spinner chiedendosi se sta succedendo qualcosa

Le risposte in background ribaltano tutto questo.

Come funzionano i token di continuazione

Invece di bloccare, lanci il compito dell’agente e ottieni un token di continuazione. Pensalo come un biglietto di ritiro in un’officina — non resti al bancone ad aspettare, torni quando è pronto.

Il flusso è diretto:

Invia la tua richiesta con AllowBackgroundResponses = true
Se l’agente supporta l’elaborazione in background, ricevi un token di continuazione
Interroga al tuo ritmo finché il token non torna null — significa che il risultato è pronto

Ecco la versione .NET:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Interrogare fino al completamento
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Se l’agente completa immediatamente (compiti semplici, modelli che non necessitano di elaborazione in background), nessun token viene restituito. Il tuo codice funziona e basta — nessuna gestione speciale necessaria.

Streaming con ripresa: la vera magia

Il polling va bene per scenari fire-and-forget, ma cosa succede quando vuoi il progresso in tempo reale? Le risposte in background supportano anche lo streaming con ripresa integrata.

Ogni aggiornamento dello stream porta il suo token di continuazione. Se la tua connessione cade a metà stream, riprendi esattamente da dove avevi lasciato:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simulare un'interruzione di rete
}

// Riprendere esattamente da dove avevamo lasciato
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

L’agente continua a elaborare lato server indipendentemente da cosa succede al tuo client. È tolleranza ai guasti integrata senza che tu scriva logica di retry o circuit breaker.

Quando usare questo concretamente

Non ogni chiamata all’agente ha bisogno di risposte in background. Per completamenti veloci, stai aggiungendo complessità senza motivo. Ma ecco dove brillano:

Compiti di ragionamento complesso — analisi multi-step, ricerca approfondita, qualsiasi cosa che faccia davvero pensare un modello di ragionamento
Generazione di contenuti lunghi — report dettagliati, documenti multi-parte, analisi estese
Reti poco affidabili — client mobili, deployment edge, VPN aziendali instabili
Pattern UX asincroni — invia un compito, vai a fare altro, torna per i risultati

Per noi sviluppatori .NET che costruiamo app enterprise, l’ultimo punto è particolarmente interessante. Pensa a un’app Blazor dove un utente richiede un report complesso — lanci il compito dell’agente, mostri un indicatore di progresso, e li lasci continuare a lavorare. Niente acrobazie WebSocket, niente infrastruttura di code personalizzata, solo un token e un loop di polling.

Per concludere

Le risposte in background sono disponibili ora sia in .NET che in Python attraverso Microsoft Agent Framework. Se stai costruendo agenti che fanno qualcosa di più complesso del semplice Q&A, vale la pena aggiungerlo al tuo toolkit. Il pattern del token di continuazione mantiene le cose semplici risolvendo un problema di produzione molto reale.

Consulta la documentazione completa per il riferimento completo dell’API e altri esempi.

VS Code 1.112: Cosa dovrebbe davvero interessare agli sviluppatori .NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 è appena atterrato, e onestamente? Questo colpisce diversamente se passi le tue giornate nel mondo .NET. C’è molto nelle note di rilascio ufficiali, ma lascia che ti risparmi un po’ di scrolling e mi concentri su quello che conta davvero per noi.

Copilot CLI è diventato molto più utile

Il grande tema di questo rilascio è l’autonomia dell’agente — dare a Copilot più spazio per fare il suo lavoro senza che tu supervisioni ogni passo.

Steering e coda dei messaggi

Conosci quel momento in cui Copilot CLI è a metà di un task e ti rendi conto che hai dimenticato di menzionare qualcosa? Prima, dovevi aspettare. Ora puoi inviare messaggi mentre una richiesta è ancora in corso — sia per dirigere la risposta corrente che per mettere in coda istruzioni di follow-up.

Questo è enorme per quei task di scaffolding dotnet più lunghi dove stai guardando Copilot configurare un progetto e pensi “oh aspetta, mi serve anche MassTransit lì dentro.”

Livelli di permessi

Questo è quello che mi entusiasma di più. Le sessioni Copilot CLI ora supportano tre livelli di permessi:

Permessi predefiniti — il flusso solito dove gli strumenti chiedono conferma prima di eseguire
Bypass approvazioni — auto-approva tutto e riprova in caso di errore
Autopilota — completamente autonomo: approva strumenti, risponde alle proprie domande e continua finché il task non è completo

Se stai facendo qualcosa come creare una nuova API ASP.NET Core con Entity Framework, migrazioni e Docker setup — la modalità Autopilota significa che descrivi quello che vuoi e vai a prendere un caffè. Lo capirà da solo.

Puoi abilitare l’Autopilota con l’impostazione chat.autopilot.enabled.

Anteprima delle modifiche prima della delega

Quando deleghi un task a Copilot CLI, crea un worktree. Prima, se avevi modifiche non committate, dovevi controllare il Source Control per vedere cosa sarebbe stato influenzato. Ora la vista Chat mostra le modifiche pendenti proprio lì prima che tu decida se copiarle, spostarle o ignorarle.

Piccola cosa, ma ti salva da quel momento “aspetta, cosa avevo in staging?”

Debug delle web app senza lasciare VS Code

Il browser integrato ora supporta il debugging completo. Puoi impostare breakpoint, fare step through del codice e ispezionare variabili — tutto dentro VS Code. Basta passare a Edge DevTools.

C’è un nuovo tipo di debug editor-browser, e se hai già configurazioni di lancio msedge o chrome esistenti, migrare è semplice come cambiare il campo type nel tuo launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Per gli sviluppatori Blazor, questo è un game changer. Stai già eseguendo dotnet watch nel terminale — ora anche il tuo debugging resta nella stessa finestra.

Il browser ha anche ottenuto livelli di zoom indipendenti (finalmente), menu contestuali con clic destro appropriati, e lo zoom viene ricordato per sito web.

Sandboxing dei server MCP

Questo conta più di quanto potresti pensare. Se usi server MCP — magari ne hai configurato uno personalizzato per le tue risorse Azure o query al database — giravano con gli stessi permessi del tuo processo VS Code. Questo significa accesso completo al tuo filesystem, rete, tutto.

Ora puoi metterli in sandbox. Nel tuo mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Quando un server sandboxato ha bisogno di accedere a qualcosa che non ha, VS Code ti chiede di concedere il permesso. Molto meglio dell’approccio “speriamo che nessuno faccia nulla di strano”.

Scoperta delle personalizzazioni nei monorepo

Se lavori in un monorepo (e siamo onesti, molte soluzioni .NET enterprise finiscono per diventarne uno), questo risolve un vero punto dolente.

Prima, se aprivi una sottocartella del tuo repo, VS Code non trovava il tuo copilot-instructions.md, AGENTS.md o skills personalizzati alla radice del repository. Ora con l’impostazione chat.useCustomizationsInParentRepositories, risale fino alla radice .git e scopre tutto.

Questo significa che il tuo team può condividere istruzioni per agenti, file di prompt e strumenti personalizzati tra tutti i progetti in un monorepo senza che tutti debbano aprire la cartella radice.

/troubleshoot per il debugging degli agenti

Hai mai configurato istruzioni personalizzate o skills e ti sei chiesto perché non vengono rilevati? Il nuovo skill /troubleshoot legge i log di debug dell’agente e ti dice cosa è successo — quali strumenti sono stati usati o saltati, perché le istruzioni non sono state caricate, e cosa sta causando risposte lente.

Abilitalo con:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Poi scrivi semplicemente /troubleshoot why is my custom skill not loading? nella chat.

Puoi anche esportare e importare questi log di debug ora, il che è ottimo per condividerli con il team quando qualcosa non funziona come previsto.

Supporto file immagine e binari

Gli agenti possono ora leggere file immagine dal disco e file binari nativamente. I file binari vengono presentati in formato hexdump, e gli output delle immagini (come screenshot dal browser integrato) appaiono in una vista carousel.

Per gli sviluppatori .NET, pensa: incolla uno screenshot di un bug UI nella chat e fai capire all’agente cosa c’è che non va, o fagli analizzare l’output del rendering di un componente Blazor.

Riferimenti automatici ai simboli

Piccolo miglioramento di qualità della vita: quando copi il nome di un simbolo (una classe, metodo, ecc.) e lo incolli nella chat, VS Code ora lo converte automaticamente in un riferimento #sym:Name. Questo dà all’agente il contesto completo su quel simbolo senza che tu debba aggiungerlo manualmente.

Se vuoi testo semplice, usa Ctrl+Shift+V.

I plugin possono ora essere abilitati/disabilitati

Prima, disabilitare un server MCP o plugin significava disinstallarlo. Ora puoi attivarli e disattivarli — sia globalmente che per workspace. Clic destro nella vista Estensioni o nella vista Personalizzazioni e hai fatto.

I plugin da npm e pypi possono anche auto-aggiornarsi ora, anche se chiederanno approvazione prima poiché gli aggiornamenti significano eseguire nuovo codice sulla tua macchina.

Per concludere

VS Code 1.112 sta chiaramente spingendo forte sull’esperienza agent — più autonomia, debugging migliore, sicurezza più stretta. Per gli sviluppatori .NET, il debugging del browser integrato e i miglioramenti di Copilot CLI sono le funzionalità di punta.

Se non hai ancora provato a eseguire una sessione completa di Copilot CLI in modalità Autopilota per un progetto .NET, questo rilascio è un buon momento per iniziare. Ricorda solo di impostare i tuoi permessi e lasciare cuocere.

Scarica VS Code 1.112 o aggiorna dall’interno di VS Code tramite Aiuto > Controlla aggiornamenti.

Dotnet | The .NET Blog

SDD Conference 2026

Argomenti

Speaker

Biglietti e informazioni

Hook azd in Python, TypeScript e .NET: basta script shell

Gli hook, in breve

Come funziona il rilevamento

Dettagli per linguaggio

Python

JavaScript e TypeScript

.NET

Configurazione per executor

Perché è importante per gli sviluppatori .NET

Conclusione

Windows App Dev CLI v0.3: F5 dal terminale e UI Automation per gli agenti

winapp run: F5 da qualsiasi posto

Nuovo pacchetto NuGet: dotnet run per le app pacchettizzate

winapp ui: UI Automation dalla riga di comando

Altre novità

Come ottenerlo

Smetti di sorvegliare il tuo terminale: la modalità detached di Aspire cambia il flusso di lavoro

Modalità detached: un comando, terminale recuperato

Gestire ciò che è in esecuzione

Combinalo con la modalità isolata

Perché questo è enorme per gli agenti di codice

Per concludere

Il Pin Clustering Arriva Finalmente in .NET MAUI Maps — Una Proprietà, Zero Problemi

Una proprietà per dominarli tutti

Gruppi di clustering indipendenti

Gestione dei tap sui cluster

Dettagli di piattaforma da conoscere

Perché è importante

Per iniziare

.NET Aprile 2026 Servicing — Patch di sicurezza da applicare oggi

Cosa è stato corretto

Versioni aggiornate

Cosa fare

Azure MCP Server 2.0 è Arrivato — L'Automazione Agentica Self-Hosted nel Cloud È Qui

Che cos’è Azure MCP Server?

Il grande affare: deployment remoti self-hosted

Hardening della sicurezza

Dove puoi usarlo?

Perché questo conta per gli sviluppatori .NET

Per iniziare

Per concludere

.NET Aspire 13.2 Vuole Essere il Migliore Amico del Tuo Agente IA

Il problema è reale

Aspire come infrastruttura per agenti

L’analogia dei parabordi del bowling

Per iniziare

Per concludere

Collega i tuoi server MCP su Azure Functions ai Foundry Agents — Ecco come

Perché questa combinazione ha senso

Opzioni di autenticazione

Configurazione

La mia opinione

Conclusione

La Modalità Isolata di Aspire Risolve l'Incubo dei Conflitti di Porta per lo Sviluppo Parallelo

La soluzione: --isolated

Scenari reali dove questo brilla

Come funziona sotto il cofano

Quando usarlo

Per concludere

La valutazione di modernizzazione di GitHub Copilot è il miglior strumento di migrazione che non stai ancora usando

Non è solo un motore di suggerimenti di codice

Due modi per iniziare

La suddivisione degli issue è azionabile

I percorsi di upgrade coperti

La mia opinione

Conclusione

Le MCP Apps hanno una Fluent API — Crea interfacce ricche per strumenti AI in .NET in tre passaggi

Cosa sono le MCP Apps?

La Fluent API in tre passaggi

La superficie dell’API è ben progettata

Per iniziare

Conclusione

C# 15 introduce i tipi union — e sono esattamente quello che stavamo chiedendo

Il problema che le union risolvono

La sintassi è di una semplicità elegante

La soluzione: `--isolated`