The .NET Blog

NDC Oslo 2026

Mon, 14 Sep 2026 00:00:00 +0000

NDC Oslo 2026 si svolge dal 14 al 18 settembre 2026 all’Oslo Spektrum, Oslo, Norvegia.

NDC Oslo è una delle conferenze per sviluppatori più grandi e rispettate in Europa, che copre tutto, da .NET e cloud a sicurezza, architettura, IA e oltre. L’edizione 2026 è attualmente in fase di prenotazione, con un programma massiccio in preparazione.

In numeri

160 sessioni (in prenotazione)
150 speaker (in prenotazione)
15 workshop (in prenotazione)
5 giorni — workshop + conferenza

Speaker confermati

La lista degli speaker è in fase di definizione, con nomi confermati tra cui:

Nick Chapsas
Maddy Montaquila
Troy Hunt
Kevlin Henney
Venkat Subramaniam
Jeff Fritz
Philippe De Ryck
Nhlanhla Lucky Nkosi
Aleksander Stensby

Biglietti

I biglietti Early Bird sono disponibili — l’offerta Early Bird scade il 22 maggio 2026.

È aperto anche il CFP (Call for Papers).

Altri eventi NDC nel 2026

NDC Sydney — 22–24 aprile 2026
NDC Toronto — 5–8 maggio 2026
NDC Copenhagen — 1–4 giugno 2026
NDC AI — 8–10 giugno 2026
NDC TechTown — 21–24 settembre 2026

Link

.NET Day Switzerland 2026

Tue, 25 Aug 2026 00:00:00 +0000

.NET Day Switzerland 2026 si svolge il 25 agosto 2026 presso l’Arena Cinemas Sihlcity (Kalanderplatz 8, 8045 Zurigo).

È una conferenza comunitaria indipendente e no-profit per sviluppatori, architetti ed esperti che vogliono discutere di .NET, C#, ASP.NET Core, Azure e dell’ecosistema di sviluppo Microsoft. Tutti gli speaker e lo staff prestano il loro tempo come volontari, e qualsiasi surplus dalla vendita dei biglietti va in beneficenza o alla community .NET svizzera.

Cosa ti aspetta

Sessioni di alta qualità con esperti internazionali
Networking con altri partecipanti
Cibo, snack e bevande durante le pause, il pranzo e l’aperitivo
Opportunità di carriera attraverso interazioni con gli sponsor
Conversazioni dirette con gli speaker durante le pause

Biglietti

Categoria	Prezzo	Disponibilità
Very Early Bird (1–30 apr)	299 CHF	Max. 100 biglietti
Early Bird	399 CHF	Max. 100 biglietti
Regular	449 CHF	Fino a esaurimento

Speaker e programma non sono ancora stati annunciati — la call for speakers è aperta su Sessionize.

Organizzatori

Link

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.

Azure DevOps MCP Server Aggiornamento Aprile: Query WIQL, Auth PAT e MCP Apps Sperimentali

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

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

Il Azure DevOps MCP Server continua a migliorare. L’aggiornamento di aprile copre entrambi i server.

Supporto Query WIQL

Il nuovo strumento wit_query_by_wiql permette di eseguire query Work Item Query Language direttamente dal client MCP.

Personal Access Tokens

Autenticazione PAT sul server locale — importante per scenari di integrazione senza autenticazione interattiva.

Annotazioni MCP

Tag di metadati per strumenti di sola lettura, distruttivi e open-world — fondamentali per l’affidabilità degli agenti.

Consolidamento degli Strumenti Wiki

5 strumenti wiki separati → 2 strumenti più capaci. Meno strumenti = migliori prestazioni LLM.

Sperimentale: MCP Apps

Workflow impacchettati nell’ambiente del server MCP. La direzione è giusta.

Post originale di Dan Hellem: Azure DevOps MCP Server April Update.

.NET 10 Arriva con Ubuntu 26.04 LTS — Le Novità

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

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

È il giorno dell’Ubuntu LTS. Ubuntu 26.04 (Resolute Raccoon) è uscito oggi con .NET 10.

LTS su LTS — cinque anni di supporto per l’OS, in linea con la finestra di supporto a lungo termine di .NET 10.

Installa .NET 10 in due comandi

sudo apt update
sudo apt install dotnet-sdk-10.0

.NET è una delle toolchain ufficialmente supportate su Ubuntu — non un add-on di terze parti.

Container: aggiorna `-noble` a `-resolute`

sed -i "s/noble/resolute/g" Dockerfile

Native AOT: avvio in 3ms, binario da 1,4MB

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# binario nativo da 1,4MB, avvio in 3ms

Per carichi di lavoro cloud-native dove il tempo di cold-start conta — Functions, container, serverless — un vero cambio di gioco.

Hai bisogno di .NET 8 o 9?

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

Il post completo ha più dettagli.

Azure MCP Server Ora è un .mcpb — Installalo senza Nessun Runtime

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

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

Sai cosa era fastidioso nella configurazione dei server MCP? Avevi bisogno di un runtime. Node.js per la versione npm, Python per pip/uvx, .NET SDK per la variante dotnet.

L’Azure MCP Server ha appena cambiato questo. È ora disponibile come .mcpb — un MCP Bundle — e la configurazione è drag-and-drop.

Cos’è un MCP Bundle?

Pensaci come a un’estensione VS Code (.vsix) o un’estensione browser (.crx), ma per i server MCP. Un file .mcpb è un archivio ZIP autonomo che include il binario del server e tutte le sue dipendenze.

Come installarlo

1. Scarica il bundle per la tua piattaforma

Vai alla pagina GitHub Releases e scarica il file .mcpb per il tuo OS e architettura.

2. Installa in Claude Desktop

Il modo più semplice: trascina il file .mcpb nella finestra di Claude Desktop sulla pagina delle impostazioni Estensioni (☰ → File → Impostazioni → Estensioni). Rivedi i dettagli del server, clicca su Installa, conferma.

3. Autenticati su Azure

az login

Fatto. Azure MCP Server usa le tue credenziali Azure esistenti.

Cosa puoi fare

Oltre 100 strumenti di servizi Azure direttamente dal tuo client AI:

Interrogare e gestire Cosmos DB, Storage, Key Vault, App Service, Foundry
Generare comandi az CLI per qualsiasi attività
Creare template Bicep e Terraform

Per iniziare

Download: GitHub Releases
Repository: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Consulta il post completo.

Azure SDK Aprile 2026: AI Foundry 2.0 e Cosa Devono Sapere gli Sviluppatori .NET

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

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

Le versioni mensili dell’SDK sono spesso facili da ignorare. Questa ha alcune cose degne di attenzione — specialmente se stai costruendo con AI Foundry, Cosmos DB in Java, o fai provisioning di infrastruttura da codice .NET.

Azure.AI.Projects 2.0.0 — Breaking Change che Hanno Senso

Split di namespace, tipi rinominati, e convenzione Is* coerente per i booleani.

Cosmos DB Java: Correzione Critica di Sicurezza (RCE)

La versione 4.79.0 corregge una vulnerabilità di Remote Code Execution (CWE-502). Aggiorna immediatamente.

Nuove Librerie di Provisioning per .NET

Post originale: Azure SDK Release (April 2026).

CodeAct in Agent Framework: Come Dimezzare la Latenza del tuo Agente

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

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

C’è quel momento in ogni progetto di agenti in cui guardi il trace e pensi: “perché ci vuole così tanto?” Il modello funziona bene. Gli strumenti funzionano. Ma ci sono sette round trip per ottenere un risultato che potresti calcolare in una sola volta.

Questo è esattamente il problema che CodeAct risolve — e il team di Agent Framework ha appena pubblicato il supporto alpha tramite il nuovo pacchetto agent-framework-hyperlight.

Cos’è CodeAct?

Il pattern CodeAct è elegantemente semplice: invece di dare al modello una lista di strumenti da chiamare uno alla volta, gli dai un unico strumento execute_code e lo lasci esprimere l’intero piano come un breve programma Python. L’agente scrive il codice una volta, la sandbox lo esegue, e ottieni un singolo risultato consolidato.

Approccio	Tempo	Token
Tradizionale	27,81s	6.890
CodeAct	13,23s	2.489
Miglioramento	52,4%	63,9%

La componente di sicurezza: Micro-VM Hyperlight

Il pacchetto agent-framework-hyperlight utilizza micro-VM di Hyperlight. Ogni chiamata execute_code ottiene la propria micro-VM appena creata. L’avvio si misura in millisecondi. L’isolamento è praticamente gratuito.

I tuoi strumenti continuano a girare sull’host. Il codice collante generato dal modello gira nella sandbox. Questa è la divisione giusta.

Configurazione minima

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Quando usare CodeAct (e quando no)

Usa CodeAct quando:

Il task concatena molte piccole chiamate a strumenti (lookup, join, calcoli)
La latenza e il costo dei token contano
Vuoi un isolamento forte per chiamata sul codice generato dal modello

Resta con il tool-calling tradizionale quando:

L’agente fa solo una o due chiamate a strumenti per turno
Ogni chiamata ha effetti collaterali da approvare individualmente
Le descrizioni degli strumenti sono scarse o ambigue

Provalo ora

pip install agent-framework-hyperlight --pre

Leggi il post completo sul blog di Agent Framework per una copertura più approfondita.

Dove il tuo Agente Ricorda le Cose? Guida Pratica all'Archiviazione della Cronologia Chat

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

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

Quando costruisci un agente IA, dedichi la maggior parte dell’energia al modello, agli strumenti e ai prompt. La domanda su dove vive la cronologia della conversazione sembra un dettaglio di implementazione — ma è una delle decisioni architetturali più importanti che prenderai.

Determina se gli utenti possono ramificare le conversazioni, annullare le risposte, riprendere le sessioni dopo un riavvio e se i tuoi dati escono mai dalla tua infrastruttura. Il team di Agent Framework ha pubblicato un’analisi approfondita.

Due pattern fondamentali

Gestito dal servizio: il servizio IA archivia lo stato della conversazione. La tua app mantiene un riferimento e il servizio include automaticamente la cronologia rilevante in ogni richiesta.

Gestito dal client: la tua app mantiene la cronologia completa e invia messaggi rilevanti con ogni richiesta. Il servizio è stateless. Tu controlli tutto.

Come Agent Framework astrae questo

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Mi chiamo Alice.", session);
var second = await agent.RunAsync("Come mi chiamo?", session);

session = agent.create_session()
first = await agent.run("Mi chiamo Alice.", session=session)
second = await agent.run("Come mi chiamo?", session=session)

Riferimento rapido ai provider

Provider	Archiviazione	Modello	Compattazione
OpenAI/Azure Chat Completions	Client	N/A	Tu
Foundry Agent Service	Servizio	Lineare	Servizio
Responses API (default)	Servizio	Ramificabile	Servizio
Anthropic Claude, Ollama	Client	N/A	Tu

Come scegliere

Hai bisogno di ramificazione o “annulla”? → Responses API gestito dal servizio
Hai bisogno di sovranità dei dati? → Gestito dal client con provider di database
È un semplice chatbot? → Gestito dal servizio lineare va benissimo

Leggi il post completo per l’albero decisionale completo.

GPT-5.5 È Arrivato su Azure Foundry — Cosa Devono Sapere i Sviluppatori .NET

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

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

Microsoft ha appena annunciato che GPT-5.5 è generalmente disponibile in Microsoft Foundry. Se stai costruendo agenti su Azure, questo è l’aggiornamento che stavi aspettando.

La progressione di GPT-5

GPT-5: ha unificato ragionamento e velocità in un unico sistema
GPT-5.4: ragionamento multi-step più solido, capacità agentiche per l’enterprise
GPT-5.5: ragionamento in contesto lungo più profondo, esecuzione agentica più affidabile, migliore efficienza dei token

Cosa è cambiato davvero

Coding agentico migliorato: GPT-5.5 mantiene il contesto su grandi codebase, diagnostica guasti architetturali e anticipa i requisiti di test. Il modello ragiona su cos’altro influenza una correzione prima di agire.

Efficienza dei token: Output di qualità superiore con meno token e meno tentativi. Costo e latenza direttamente inferiori in produzione.

Analisi in contesto lungo: Gestisce documenti estesi e cronologie multi-sessione senza perdere il filo.

Prezzi

Modello	Input ($/M token)	Input in cache	Output ($/M token)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Perché Foundry è importante

Foundry Agent Service permette di definire agenti in YAML o collegarli con Microsoft Agent Framework, GitHub Copilot SDK, LangGraph o OpenAI Agents SDK — ed eseguirli come agenti ospitati isolati con filesystem persistente, identità Microsoft Entra e prezzi scale-to-zero.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Sei un assistente utile.", name: "MioAgente");

Consulta l’annuncio completo per tutti i dettagli.

VS Code 1.118: Copilot CLI ottiene Nomi di Sessione, Badge di Modello e TypeScript 7.0 Nightly

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

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

Visual Studio Code 1.118 è una release più piccola e focalizzata — principalmente raffinamenti di Copilot CLI.

Copilot CLI: le sessioni hanno nomi reali

Le API di titolo di sessione dell’SDK di Copilot CLI vengono ora usate come fonte di verità per i nomi delle sessioni. Invece di etichette auto-generate, le sessioni mostrano il nome reale dall’SDK.

Cambia sessione più velocemente

L’app Agents ha ora Ctrl+1, Ctrl+2, ecc. per passare rapidamente tra le sessioni.

Badge modello nella chat

Le risposte di Copilot CLI nel pannello chat mostrano ora un badge modello — puoi vedere a colpo d’occhio quale modello ha gestito ogni richiesta.

Selezione automatica del modello in Copilot CLI

La selezione automatica del modello funziona ora anche nell’agente Copilot CLI.

Opt-in per TypeScript 7.0 Nightly

Puoi ora optare per testare i nightly di TypeScript 7.0 direttamente dalle impostazioni di VS Code. TypeScript 7.0 è un release importante (la beta è uscita pochi giorni fa).

Consulta le note di release complete.

Aspire 13.2: Supporto Bun, Contenitori Migliori e Meno Attrito nel Debug

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

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

Se stai costruendo backend .NET con frontend JavaScript in Aspire, la 13.2 è l’aggiornamento che migliora silenziosamente la tua giornata.

Bun è Ora di Prima Classe

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Se il tuo team usa già Bun, Aspire non ti costringe più a nuotare controcorrente.

Yarn Più Affidabile

Gli utenti Yarn ottengono meno errori misteriosi con withYarn() e addViteApp().

Miglioramenti ai Container

ImagePullPolicy.Never per usare l’immagine locale senza andare al registry. PostgreSQL 18+ con volumi di dati ora funziona correttamente.

Miglioramenti al Debug

DebuggerDisplayAttribute sui tipi core
Messaggi di errore migliori per WaitFor
BeforeResourceStartedEvent si attiva al momento giusto

Post originale di David Pine: Aspire 13.2: Bun Support and Container Enhancements.

68 Minuti al Giorno a Ri-Spiegare il Codice? C'è una Soluzione

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

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

Conosci quel momento in cui la tua sessione di Copilot raggiunge /compact e l’agente dimentica completamente su cosa stavi lavorando? Passi i successivi cinque minuti a ri-spiegare la struttura dei file, il test fallito, i tre approcci già provati. Poi succede di nuovo.

Desi Villanueva l’ha cronometrato: 68 minuti al giorno — solo per il riorientamento. Non scrivendo codice. Non rivedendo PR. Solo aggiornando l’IA su cose che già sapeva.

La Bugia della Finestra di Contesto

Il tuo agente arriva con un numero grande sulla scatola. 200K token. Sembra massiccio. In pratica è un soffitto, non una garanzia.

La matematica reale: circa 125K prima di digitare una parola, e il limite effettivo è 45K token prima che la qualità degrade — a causa del problema “lost in the middle” degli LLM.

La Tassa di Compattazione

La parte crudele: la memoria esiste già. Copilot CLI scrive ogni sessione in un database SQLite locale in ~/.copilot/session-store.db. L’agente semplicemente non può leggerlo.

auto-memory: Uno Strato di Richiamo, Non un Sistema di Memoria

pip install auto-memory

~1.900 righe di Python. Zero dipendenze. Installato in 30 secondi.

50 token invece di 10.000 — accesso chirurgico ai file che hai toccato ieri, non un diluvio di risultati grep irrilevanti.

Conclusione

Il context rot è un vero vincolo architetturale. auto-memory lo aggira dando al tuo agente un meccanismo di richiamo economico e preciso.

Dai un’occhiata: auto-memory su GitHub. Post originale di Desi Villanueva: I Wasted 68 Minutes a Day.

Foundry Toolboxes: Un unico endpoint per tutti i tool degli agenti

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

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

C’è un problema che sembra noioso finché non lo si vive in prima persona: l’organizzazione sta costruendo più agenti IA, ognuno ha bisogno di tool, e ogni team li riconfigura da zero. La stessa integrazione di ricerca web, la stessa config di Azure AI Search, la stessa connessione al server MCP di GitHub — ma in un altro repository, da un altro team, con altre credenziali e senza governance condivisa.

Microsoft Foundry ha appena lanciato Toolboxes in public preview, ed è una risposta diretta a questo problema.

Cos’è una Toolbox?

Una Toolbox è un bundle di tool con nome, riutilizzabile, che si definisce una volta in Foundry e si espone tramite un unico endpoint compatibile MCP. Qualsiasi runtime di agente che parla MCP può consumarlo — nessun lock-in con Foundry Agents.

La promessa è semplice: build once, consume anywhere. Definisci i tool, configura l’autenticazione centralmente (OAuth passthrough, identità gestita di Entra), pubblica l’endpoint. Ogni agente che ha bisogno di quei tool si connette all’endpoint e li ottiene tutti.

I quattro pilastri (due disponibili oggi)

Pilastro	Stato	Cosa fa
Discover	In arrivo	Trova tool approvati senza ricerca manuale
Build	Disponibile	Raggruppa tool in un bundle riutilizzabile
Consume	Disponibile	Un endpoint MCP unico espone tutti i tool
Govern	In arrivo	Auth centralizzata + observability per tutte le chiamate

Esempio pratico

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Cerca documentazione e rispondi alle issue di GitHub.",
 tools=[
 {"type": "web_search", "description": "Cerca documentazione pubblica"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Una volta pubblicato, Foundry fornisce un endpoint unificato. Una connessione, tutti i tool.

Nessun lock-in con Foundry Agents

Le Toolbox vengono create e gestite in Foundry, ma la superficie di consumo è il protocollo MCP aperto. Si possono usare da agenti personalizzati (Microsoft Agent Framework, LangGraph), GitHub Copilot e altri IDE compatibili MCP.

Perché è importante adesso

L’ondata multi-agente sta arrivando in produzione. Ogni nuovo agente è una nuova superficie per configurazione duplicata, credenziali scadute e comportamento inconsistente. La base Build + Consume è sufficiente per iniziare a centralizzare. Quando arriverà il pilastro Govern, si avrà uno strato di tool completamente osservabile e controllato centralmente per tutta la flotta di agenti.

Conclusione

È ancora presto — public preview, SDK Python prima, con Discover e Govern ancora in arrivo. Ma il modello è solido e il design nativo MCP significa che funziona con i tool che si stanno già costruendo. Dai un’occhiata all’annuncio ufficiale per iniziare.

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.

azd + GitHub Copilot: Configurazione del progetto con IA e risoluzione intelligente degli errori

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Conosci quel momento in cui vuoi fare il deploy di un’app esistente su Azure e ti ritrovi a fissare un azure.yaml vuoto, cercando di ricordare se la tua API Express dovrebbe usare Container Apps o App Service? Quel momento è appena diventato molto più breve.

L’Azure Developer CLI (azd) si integra ora con GitHub Copilot in due modi concreti: scaffolding assistito dall’IA durante azd init, e risoluzione intelligente degli errori quando i deployment falliscono. Entrambe le funzionalità rimangono completamente nel terminale — esattamente dove voglio che siano.

Configurazione con Copilot durante azd init

Quando esegui azd init, ora compare l’opzione “Set up with GitHub Copilot (Preview)”. Selezionala e Copilot analizza la tua codebase per generare azure.yaml, i template di infrastruttura e i moduli Bicep — basandosi sul tuo codice reale.

azd init
# Seleziona: "Set up with GitHub Copilot (Preview)"

Prerequisiti:

azd 1.23.11 o superiore — verifica con azd version o aggiorna con azd update
Abbonamento attivo a GitHub Copilot (Individual, Business o Enterprise)
GitHub CLI (gh) — azd chiederà il login se necessario

Quello che trovo genuinamente utile: funziona in entrambi i sensi. Stai costruendo da zero? Copilot ti aiuta a configurare i servizi Azure giusti sin dall’inizio. Hai un’app esistente che volevi deployare da tempo? Punta Copilot su di essa e genera la configurazione senza che tu debba ristrutturare nulla.

Cosa fa davvero

Diciamo che hai un’API Express Node.js con dipendenza da PostgreSQL. Invece di decidere manualmente tra Container Apps e App Service, e poi scrivere Bicep da zero, Copilot rileva il tuo stack e genera:

Un azure.yaml con le impostazioni corrette di language, host e build
Un modulo Bicep per Azure Container Apps
Un modulo Bicep per Azure Database for PostgreSQL

E prima di toccare qualsiasi cosa esegue verifiche preventive — controlla che la tua directory git sia pulita, chiede il consenso per gli strumenti del server MCP. Niente accade senza che tu sappia esattamente cosa sta per cambiare.

Risoluzione degli errori con Copilot

Gli errori di deployment sono inevitabili. Parametri mancanti, problemi di permessi, disponibilità degli SKU — e il messaggio d’errore raramente ti dice l’unica cosa che hai davvero bisogno di sapere: come risolverlo.

Senza Copilot, il ciclo è: copiare l’errore → cercare nella documentazione → leggere tre risposte irrilevanti su Stack Overflow → eseguire alcuni comandi az CLI → riprovare sperando. Con Copilot integrato in azd, questo ciclo collassa. Quando qualsiasi comando azd fallisce, offre immediatamente quattro opzioni:

Explain — spiegazione in linguaggio naturale di cosa è andato storto
Guidance — istruzioni passo dopo passo per correggere il problema
Diagnose and Guide — analisi completa + Copilot applica la correzione (con la tua approvazione) + retry opzionale
Skip — gestire da soli

Il punto cruciale: Copilot ha già il contesto del tuo progetto, il comando che ha fallito e l’output dell’errore. I suoi suggerimenti sono specifici per la tua situazione, non documentazione generica.

Configurare il comportamento predefinito

Se scegli sempre la stessa opzione, salta il prompt interattivo:

azd config set copilot.errorHandling.category troubleshoot

Valori: explain, guidance, troubleshoot, fix, skip. Puoi anche abilitare auto-fix e retry:

azd config set copilot.errorHandling.fix allow

Ritorno alla modalità interattiva in qualsiasi momento:

azd config unset copilot.errorHandling.category

Conclusione

Questo è esattamente il tipo di integrazione di Copilot che porta valore reale. Provalo eseguendo azd update per ottenere l’ultima versione e usa azd init nel tuo prossimo progetto.

Leggi l’annuncio originale qui.

Scrivere addon nativi Node.js in C# con .NET Native AOT

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Uno scenario che adoro: un team che lavora su strumenti .NET aveva addon nativi Node.js scritti in C++ e compilati tramite node-gyp. Funzionava. Ma richiedeva Python installato su ogni macchina dello sviluppatore — una vecchia versione di Python, per giunta — solo per costruire un pacchetto che nessuno nel team avrebbe mai toccato direttamente.

Si sono quindi posti una domanda molto ragionevole: abbiamo già il SDK .NET installato, perché stiamo scrivendo C++?

La risposta è stata Native AOT, e il risultato è genuinamente elegante.

L’idea di base

Un addon nativo Node.js è una libreria condivisa (.dll su Windows, .so su Linux, .dylib su macOS) che Node.js può caricare a runtime. L’interfaccia si chiama N-API — una API C stabile e compatibile con ABI. A N-API non importa quale linguaggio ha prodotto la libreria, solo che esporti i simboli giusti.

.NET Native AOT può produrre esattamente questo. Compila il codice C# ahead-of-time in una libreria nativa condivisa con punti di ingresso arbitrari. Questo è tutto il trucco.

Setup del progetto

Il file di progetto è minimale:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot dice all’SDK di produrre una libreria condivisa a dotnet publish. AllowUnsafeBlocks è necessario per l’interop N-API con puntatori a funzione e buffer fissi.

Esportare il punto di ingresso

Node.js si aspetta che la tua libreria esporti napi_register_module_v1. In C#, [UnmanagedCallersOnly] fa esattamente questo:

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

Cose da notare: nint è un intero di dimensione nativa — l’equivalente gestito di intptr_t. Il suffisso u8 produce un ReadOnlySpan<byte> con un letterale stringa UTF-8, passato direttamente a N-API senza alcuna allocazione di encoding. E [UnmanagedCallersOnly] esporta il metodo con esattamente il nome del punto di ingresso che Node.js cerca.

Risolvere N-API contro il processo host

Le funzioni N-API sono esportate da node.exe stesso, non da una libreria separata. Quindi invece di linkare contro qualcosa, le si risolve contro il processo in esecuzione all’avvio:

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

Con questo in place, le dichiarazioni P/Invoke funzionano correttamente con [LibraryImport] e marshalling generato da sorgente.

Una funzione esportata reale

Ecco il lettore del registro che hanno costruito:

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

Nota importante sul try/catch: un’eccezione non gestita in un metodo [UnmanagedCallersOnly] fa crashare il processo host. Cattura sempre e passa a JavaScript tramite ThrowError.

Chiamarlo da TypeScript

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk', 'InstallLocation');

TypeScript → C#, senza Python, senza C++.

Cosa hanno guadagnato

La vittoria immediata è stata nell’esperienza dei contributori: nessuna versione Python specifica necessaria, yarn install funziona con solo Node.js e il SDK .NET. Anche le pipeline CI sono diventate più semplici. Le prestazioni sono state comparabili all’implementazione C++.

Conclusione

Il team C# Dev Kit ha sostituito il carico di Python/C++ con codice C# pulito che tutto il team sa già scrivere e debuggare. Per il walkthrough completo con tutti gli helper di marshalling delle stringhe, dai un’occhiata all’articolo originale sul blog .NET.

VS Code 1.117: Gli Agent Stanno Ottenendo i Propri Branch Git e Io Sono Tutto a Favore

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

La linea tra “assistente IA” e “compagno di squadra IA” continua ad assottigliarsi. VS Code 1.117 è appena uscito e le note di rilascio complete sono piene, ma la storia è chiara: gli agent stanno diventando cittadini di prima classe nel tuo workflow di sviluppo.

Ecco cosa conta davvero.

La modalità Autopilot finalmente ricorda la tua preferenza

Prima, dovevi riattivare Autopilot ogni volta che iniziavi una nuova sessione. Fastidioso. Ora la tua modalità di permessi persiste tra le sessioni, e puoi configurare il valore predefinito.

L’Agent Host supporta tre configurazioni di sessione:

Default — gli strumenti chiedono conferma prima di eseguire
Bypass — approva tutto automaticamente
Autopilot — completamente autonomo, risponde alle proprie domande e va avanti

Se stai creando un nuovo progetto .NET con migrazioni, Docker e CI — impostalo su Autopilot una volta e dimenticatene. Quella preferenza resta.

Worktree e isolamento git per le sessioni degli agent

Questa è la grande novità. Le sessioni degli agent ora supportano l’isolamento completo con worktree e git. Questo significa che quando un agent lavora su un task, ottiene il proprio branch e la propria directory di lavoro. Il tuo branch principale resta intatto.

Ancora meglio — Copilot CLI genera nomi di branch significativi per queste sessioni worktree. Basta con agent-session-abc123. Ottieni qualcosa che descrive davvero cosa sta facendo l’agent.

Per gli sviluppatori .NET che gestiscono più feature branch o correggono bug mentre un lungo task di scaffolding è in esecuzione, questo è un punto di svolta. Puoi avere un agent che costruisce i tuoi controller API in un worktree mentre tu fai debug di un problema nel service layer in un altro. Nessun conflitto. Nessun stashing. Nessun casino.

Subagent e team di agent

L’Agent Host Protocol ora supporta i subagent. Un agent può avviare altri agent per gestire parti di un task. Pensalo come delegare — il tuo agent principale coordina, e agent specializzati si occupano dei pezzi.

Siamo ancora all’inizio, ma il potenziale per i workflow .NET è ovvio. Immagina un agent che gestisce le tue migrazioni EF Core mentre un altro configura i tuoi test di integrazione. Non siamo ancora completamente lì, ma il fatto che il supporto al protocollo arrivi ora significa che gli strumenti seguiranno velocemente.

L’output del terminale incluso automaticamente quando gli agent inviano input

Piccolo ma significativo. Quando un agent invia input al terminale, l’output del terminale viene ora automaticamente incluso nel contesto. Prima, l’agent doveva fare un turno extra solo per leggere cosa era successo.

Se hai mai visto un agent eseguire dotnet build, fallire, e poi fare un altro giro solo per vedere l’errore — quella frizione è sparita. Vede l’output immediatamente e reagisce.

L’app Agents su macOS si aggiorna automaticamente

L’app standalone Agents su macOS ora si aggiorna automaticamente. Basta scaricare manualmente nuove versioni. Resta semplicemente aggiornata.

Le cose più piccole che vale la pena sapere

Gli hover su package.json ora mostrano sia la versione installata che l’ultima disponibile. Utile se gestisci strumenti npm insieme ai tuoi progetti .NET.
Le immagini nei commenti JSDoc vengono renderizzate correttamente negli hover e nei completamenti.
Le sessioni Copilot CLI ora indicano se sono state create da VS Code o esternamente — comodo quando salti tra i terminali.
Copilot CLI, Claude Code e Gemini CLI sono riconosciuti come tipi di shell. L’editor sa cosa stai eseguendo.

Il punto chiave

VS Code 1.117 non è un dump di feature appariscenti. È infrastruttura. Isolamento con worktree, permessi persistenti, protocolli per subagent — questi sono i mattoni per un workflow dove gli agent gestiscono task reali e paralleli senza pestare il tuo codice.

Se stai sviluppando con .NET e non ti sei ancora buttato nel workflow agentico, onestamente, ora è il momento di iniziare.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 si tiene il 18 aprile 2026 al Kinépolis Diversia ad Alcobendas, Madrid. È il più grande evento comunitario Azure in Spagna, con 38 speaker su 3 track paralleli dedicati ad agenti IA, networking Azure, Cosmos DB, Fabric, IoT, sicurezza e molto altro.

L’evento si svolge dalle 08:30 alle 18:30 e include keynote, pause caffè, pranzo e una sessione di chiusura Q&A.

Punti salienti dell’agenda

Domando Agentes de IA: governance, strumenti e API con Azure AI Foundry e Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: sistemi multi-agente in azione
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Biglietti

L’iscrizione prevede una donazione simbolica — l’intero prezzo del biglietto va direttamente a Plan International, a sostegno dei diritti dei bambini e dell’uguaglianza nel mondo. Posti limitati, prenota il tuo posto in anticipo.

Azure Tour 2026

Oltre a Madrid, il Global Azure Tour 2026 prevede tappe anche a Saragozza, Tenerife e Siviglia.

I tuoi esperimenti IA su Azure stanno bruciando soldi — Ecco come risolvere

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

Se stai costruendo app basate sull’IA su Azure in questo momento, probabilmente hai notato qualcosa: la tua bolletta cloud è diversa rispetto a prima. Non solo più alta — più strana. A picchi. Difficile da prevedere.

Microsoft ha appena pubblicato un ottimo articolo sui principi di ottimizzazione dei costi cloud che contano ancora, e onestamente, il tempismo non potrebbe essere migliore. Perché i carichi di lavoro IA hanno cambiato le regole del gioco per quanto riguarda i costi.

Perché i carichi di lavoro IA colpiscono diversamente

Ecco il punto. I carichi di lavoro .NET tradizionali sono relativamente prevedibili. Conosci il tuo tier App Service, conosci i tuoi DTU SQL, puoi stimare la spesa mensile abbastanza precisamente. Carichi di lavoro IA? Non proprio.

Stai testando più modelli per vedere quale si adatta. Stai avviando infrastruttura con GPU per il fine-tuning. Stai facendo chiamate API ad Azure OpenAI dove il consumo di token varia enormemente in base alla lunghezza del prompt e al comportamento degli utenti. Ogni esperimento costa soldi veri, e potresti farne decine prima di trovare l’approccio giusto.

Questa imprevedibilità è ciò che rende l’ottimizzazione dei costi critica — non come un ripensamento, ma dal primo giorno.

Gestione vs. ottimizzazione — conosci la differenza

Una distinzione dell’articolo che secondo me gli sviluppatori trascurano: c’è una differenza tra gestione dei costi e ottimizzazione dei costi.

La gestione è tracciamento e reporting. Imposti budget in Azure Cost Management, ricevi avvisi, vedi dashboard. Questo è il minimo indispensabile.

L’ottimizzazione è dove prendi effettivamente le decisioni. Hai davvero bisogno di quel tier S3, o l’S1 gestirebbe il tuo carico? Quell’istanza di compute sempre attiva sta ferma nei weekend? Potresti usare istanze spot per i tuoi job di addestramento?

Come sviluppatori .NET, tendiamo a concentrarci sul codice e lasciare le decisioni sull’infrastruttura al “team ops”. Ma se stai facendo deploy su Azure, quelle decisioni sono anche le tue.

Cosa funziona davvero

Basandomi sull’articolo e sulla mia esperienza personale, ecco cosa fa la differenza:

Sappi cosa stai spendendo e dove. Tagga le tue risorse. Sul serio. Se non riesci a capire quale progetto o esperimento sta mangiando il tuo budget, non puoi ottimizzare nulla. Azure Cost Management con un tagging appropriato è il tuo migliore amico.

Metti dei guardrail prima di sperimentare. Usa Azure Policy per limitare SKU costosi negli ambienti dev/test. Imposta limiti di spesa sui tuoi deployment Azure OpenAI. Non aspettare che arrivi la bolletta per scoprire che qualcuno ha lasciato un cluster GPU acceso tutto il weekend.

Ridimensiona continuamente. Quella VM che hai scelto durante il prototipo? Probabilmente è sbagliata per la produzione. Azure Advisor ti dà raccomandazioni — guardale davvero. Rivedi mensilmente, non annualmente.

Pensa al ciclo di vita. Le risorse di sviluppo dovrebbero spegnersi. Gli ambienti di test non devono girare 24/7. Usa policy di spegnimento automatico. Per i carichi di lavoro IA nello specifico, considera opzioni serverless dove paghi per esecuzione invece di mantenere il compute attivo.

Misura il valore, non solo il costo. Questa è facile da dimenticare. Un modello che costa di più ma fornisce risultati significativamente migliori potrebbe essere la scelta giusta. L’obiettivo non è spendere il meno possibile — è spendere in modo intelligente.

Il punto chiave

L’ottimizzazione dei costi cloud non è una pulizia una tantum. È un’abitudine. E con i carichi di lavoro IA che rendono la spesa meno prevedibile che mai, costruire questa abitudine presto ti risparmia sorprese dolorose in futuro.

Se sei uno sviluppatore .NET che costruisce su Azure, inizia a trattare la tua bolletta cloud come tratti il tuo codice — rivedila regolarmente, fai refactoring quando diventa disordinata, e non fare mai deploy senza capire quanto ti costerà.

L'RFT di Foundry è ora più economico e intelligente — Ecco cosa è cambiato

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

Se state sviluppando app .NET che si basano su modelli fine-tunati, gli aggiornamenti Foundry di questo mese meritano la vostra attenzione. Il Reinforcement Fine-Tuning è diventato più accessibile e significativamente più economico.

I dettagli completi sono nell’annuncio ufficiale, ma ecco il riassunto pratico.

Addestramento Globale per o4-mini

o4-mini è il modello di riferimento per workload pesanti in ragionamento e agentici. La grande notizia: ora potete lanciare job di fine-tuning da più di 13 regioni Azure con tariffe di addestramento per token più basse rispetto all’addestramento Standard. Stessa infrastruttura, stessa qualità, maggiore copertura.

Se il vostro team è distribuito geograficamente, questo conta. Non siete più vincolati a un pugno di regioni per addestrare.

Ecco la chiamata API REST per avviare un job di addestramento globale:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Quel flag trainingType: globalstandard è la differenza chiave.

Nuovi Valutatori di Modello: Famiglia GPT-4.1

I valutatori definiscono il segnale di ricompensa contro cui il vostro modello ottimizza. Finora, i valutatori basati su modello erano limitati a un insieme più ristretto di modelli. Ora avete tre nuove opzioni: GPT-4.1, GPT-4.1-mini e GPT-4.1-nano.

Quando dovreste usare valutatori di modello invece di quelli deterministici? Quando l’output del vostro task è aperto, quando avete bisogno di punteggio parziale su più dimensioni, o quando state costruendo workflow agentici dove la correttezza delle chiamate agli strumenti dipende dal contesto semantico.

Il punto è che la strategia a livelli è pratica:

GPT-4.1-nano per le iterazioni iniziali. Basso costo, cicli di feedback rapidi.
GPT-4.1-mini una volta che la vostra rubrica di valutazione è stabile e avete bisogno di maggiore fedeltà.
GPT-4.1 per la valutazione in produzione o rubriche complesse dove ogni decisione di punteggio conta.

Potete persino mescolare tipi di valutatori in un singolo job RFT. Usate string-match per la dimensione “risposta corretta” e un valutatore di modello per valutare la qualità del ragionamento. Questa flessibilità è onestamente ciò che lo rende utile per workload reali.

La Trappola del Formato Dati RFT

Questo fa inciampare molti. Il formato dati RFT è diverso da SFT. L’ultimo messaggio in ogni riga deve avere il ruolo User o Developer — non Assistant. La risposta attesa va in una chiave di livello superiore come reference_answer che il valutatore referenzia direttamente.

Se stavate facendo supervised fine-tuning e volete passare a RFT, dovete ristrutturare i vostri dati di addestramento. Non saltate questo passaggio o i vostri job falliranno silenziosamente.

Perché Questo È Importante per gli Sviluppatori .NET

Se state chiamando modelli fine-tunati dalle vostre app .NET tramite l’SDK Azure OpenAI, un addestramento più economico significa che potete iterare in modo più aggressivo. Le opzioni dei valutatori di modello significano che potete fare fine-tuning per task sfumati — non solo scenari di corrispondenza esatta. E la guida alle best practice su GitHub vi farà risparmiare tempo reale di debugging.

Iniziate in piccolo. Da dieci a cento campioni. Valutatore semplice. Validate il ciclo. Poi scalate.

Docker Sandbox permette agli agenti Copilot di refactorizzare il codice senza mettere a rischio la tua macchina

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

Se hai usato la modalità agente di Copilot per qualcosa di più di piccole modifiche, conosci il dolore. Ogni scrittura di file, ogni comando nel terminale — un altro prompt di permessi. Ora immagina di farlo su 50 progetti. Non è divertente.

Il team di Azure ha appena pubblicato un post su Docker Sandbox per gli agenti di GitHub Copilot, e onestamente, è uno dei miglioramenti più pratici che abbia mai visto nel tooling agentico. Utilizza microVM per dare a Copilot un ambiente completamente isolato dove può fare di tutto — installare pacchetti, eseguire build, lanciare test — senza toccare il tuo sistema host.

Cosa ti offre realmente Docker Sandbox

L’idea di base è semplice: avviare una microVM leggera con un ambiente Linux completo, sincronizzare il tuo workspace al suo interno e lasciare che l’agente Copilot operi liberamente dentro. Quando ha finito, le modifiche vengono sincronizzate indietro.

Ecco cosa lo rende più di un semplice “eseguire roba in un container”:

Sincronizzazione bidirezionale del workspace che preserva i percorsi assoluti. La struttura del tuo progetto appare identica dentro la sandbox. Nessun fallimento di build legato ai percorsi.
Docker daemon privato in esecuzione dentro la microVM. L’agente può costruire ed eseguire container senza mai montare il socket Docker del tuo host. Questo è un grande vantaggio per la sicurezza.
Proxy di filtraggio HTTP/HTTPS che controllano cosa l’agente può raggiungere sulla rete. Tu decidi quali registry ed endpoint sono consentiti. Attacchi alla supply chain da un npm install malevolo nella sandbox? Bloccati.
Modalità YOLO — sì, la chiamano proprio così. L’agente gira senza prompt di permessi perché letteralmente non può danneggiare il tuo host. Ogni azione distruttiva è contenuta.

Perché gli sviluppatori .NET dovrebbero interessarsi

Pensa al lavoro di modernizzazione che così tanti team stanno affrontando in questo momento. Hai una soluzione .NET Framework con 30 progetti e devi migrarla a .NET 9. Sono centinaia di modifiche ai file — file di progetto, aggiornamenti dei namespace, sostituzioni di API, migrazioni NuGet.

Con Docker Sandbox, puoi puntare un agente Copilot su un progetto, lasciarlo refactorizzare liberamente dentro la microVM, eseguire dotnet build e dotnet test per validare, e accettare solo le modifiche che funzionano davvero. Nessun rischio che distrugga accidentalmente il tuo ambiente di sviluppo locale mentre sperimenta.

Il post descrive anche l’esecuzione di una flotta di agenti paralleli — ognuno nella propria sandbox — che lavorano su diversi progetti contemporaneamente. Per soluzioni .NET di grandi dimensioni o architetture a microservizi, questo è un enorme risparmio di tempo. Un agente per servizio, tutti in esecuzione isolata, tutti validati indipendentemente.

L’aspetto sicurezza conta

Ecco il punto che la maggior parte delle persone trascura: quando lasci che un agente IA esegua comandi arbitrari, gli stai affidando l’intera macchina. Docker Sandbox ribalta questo modello. L’agente ottiene piena autonomia in un ambiente usa e getta. Il proxy di rete assicura che possa scaricare solo da fonti approvate. Il tuo filesystem host, il Docker daemon e le tue credenziali restano intatti.

Per i team con requisiti di compliance — e questo vale per la maggior parte delle aziende .NET — questa è la differenza tra “non possiamo usare l’IA agentica” e “possiamo adottarla in sicurezza.”

Conclusione

Docker Sandbox risolve la tensione fondamentale del coding agentico: gli agenti hanno bisogno di libertà per essere utili, ma la libertà sulla tua macchina host è pericolosa. Le microVM ti danno entrambe le cose. Se stai pianificando qualsiasi refactoring o modernizzazione .NET su larga scala, vale la pena configurarlo ora. La combinazione dell’intelligenza di codice di Copilot con un ambiente di esecuzione sicuro è esattamente ciò che i team di produzione stavano aspettando.

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.

Gli strumenti Azure MCP sono ora integrati in Visual Studio 2022 — Nessuna estensione necessaria

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

Se hai usato gli strumenti Azure MCP in Visual Studio tramite l’estensione separata, conosci il rituale — installare il VSIX, riavviare, sperare che non si rompa nulla, gestire le incompatibilità di versione. Quella frizione è finita.

Yun Jung Choi ha annunciato che gli strumenti Azure MCP vengono ora distribuiti direttamente come parte del carico di lavoro di sviluppo Azure in Visual Studio 2022. Nessuna estensione. Nessun VSIX. Nessun balletto del riavvio.

Cosa significa concretamente

A partire da Visual Studio 2022 versione 17.14.30, il Azure MCP Server è incluso nel carico di lavoro di sviluppo Azure. Se hai già quel carico di lavoro installato, basta attivarlo in GitHub Copilot Chat e sei a posto.

Oltre 230 strumenti per 45 servizi Azure — accessibili direttamente dalla finestra di chat. Elenca i tuoi account di archiviazione, fai il deploy di un’app ASP.NET Core, diagnostica problemi di App Service, interroga Log Analytics — tutto senza aprire una scheda del browser.

Perché questo conta più di quanto sembri

Il punto sugli strumenti per sviluppatori è questo: ogni passaggio in più è frizione, e la frizione uccide l’adozione. Avere MCP come estensione separata significava incompatibilità di versione, errori di installazione e un’altra cosa da tenere aggiornata. Integrarlo nel carico di lavoro significa:

Un unico percorso di aggiornamento tramite il Visual Studio Installer
Nessuna divergenza di versione tra l’estensione e l’IDE
Sempre aggiornato — il MCP Server si aggiorna con i rilasci regolari di VS

Per i team che standardizzano su Azure, questo è un grande vantaggio. Installi il carico di lavoro una volta, attivi gli strumenti, e sono disponibili per ogni sessione.

Cosa puoi farci

Gli strumenti coprono l’intero ciclo di vita dello sviluppo tramite Copilot Chat:

Imparare — chiedi informazioni sui servizi Azure, best practice, pattern architetturali
Progettare e sviluppare — ottieni raccomandazioni sui servizi, configura il codice dell’applicazione
Fare deploy — provisiona risorse e fai il deploy direttamente dall’IDE
Risolvere problemi — interroga i log, verifica lo stato delle risorse, diagnostica problemi in produzione

Un esempio rapido — scrivi questo in Copilot Chat:

List my storage accounts in my current subscription.

Copilot chiama gli strumenti Azure MCP dietro le quinte, interroga le tue sottoscrizioni e restituisce una lista formattata con nomi, posizioni e SKU. Niente portale necessario.

Come attivarlo

Aggiorna a Visual Studio 2022 17.14.30 o superiore
Assicurati che il carico di lavoro Azure development sia installato
Apri GitHub Copilot Chat
Clicca sul pulsante Select tools (l’icona delle due chiavi)
Attiva Azure MCP Server

Tutto qui. Rimane attivato tra le sessioni.

Un’avvertenza

Gli strumenti sono disattivati per default — devi attivarli manualmente. E gli strumenti specifici per VS 2026 non sono disponibili in VS 2022. La disponibilità degli strumenti dipende anche dai permessi della tua sottoscrizione Azure, come nel portale.

Il quadro generale

Questo fa parte di una tendenza chiara: MCP sta diventando lo standard per esporre gli strumenti cloud negli IDE di sviluppo. Abbiamo già visto il rilascio stabile di Azure MCP Server 2.0 e integrazioni MCP in VS Code e altri editor. Averlo integrato nel sistema dei carichi di lavoro di Visual Studio è la naturale evoluzione.

Per noi sviluppatori .NET che viviamo in Visual Studio, questo elimina un altro motivo per fare context-switch verso il portale Azure. E onestamente, meno cambi di scheda si fanno, meglio è.

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.

Aspire 13.2 aggiunge MongoDB EF Core e Azure Data Lake — Due integrazioni da provare

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

Aspire 13.2 è appena arrivato con due nuove integrazioni database che meritano la vostra attenzione: MongoDB Entity Framework Core e Azure Data Lake Storage. Se volevate usare EF Core con MongoDB in un’app Aspire, o avevate bisogno di collegare workload data lake con il service discovery, questa release offre entrambe le cose.

MongoDB incontra EF Core in Aspire

Questa è quella che mi entusiasma di più. Aspire supporta MongoDB da un po’, ma è sempre stato il driver grezzo — niente EF Core, niente DbContext, niente query LINQ sui vostri documenti. Ora avete l’esperienza completa di EF Core con MongoDB, più gli health check automatici e il service discovery di Aspire.

La configurazione segue il classico pattern di Aspire. Nel vostro AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Poi nel progetto consumatore, aggiungete l’integrazione EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

E registrate il vostro DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Da lì in poi, è EF Core standard. Definite le vostre entità, usate il vostro DbContext come fareste con qualsiasi altro provider. L’integrazione gestisce il connection pooling, le trace OpenTelemetry e gli health check dietro le quinte.

Per gli sviluppatori .NET che usavano MongoDB con il driver grezzo e configuravano le connection string manualmente, questo è un bel miglioramento. Ottenete l’astrazione completa di EF Core senza perdere il service discovery di Aspire.

Azure Data Lake Storage entra in gioco

La seconda grande aggiunta è un’integrazione Azure Data Lake Storage (ADLS). Se state costruendo pipeline di dati, processi ETL o piattaforme di analisi, ora potete collegare risorse Data Lake allo stesso modo di qualsiasi altra dipendenza Aspire.

Nell’AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Nel progetto consumatore:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Nessuna gestione manuale delle connection string, nessuna caccia alle credenziali. Aspire effettua il provisioning delle risorse e le inietta. Per chi di noi costruisce app .NET cloud-native che toccano sia dati operazionali che workload analitici, questo fa sentire il data lake come un cittadino di prima classe nel modello Aspire.

Le piccole correzioni che contano

Oltre alle funzionalità principali, ci sono alcuni miglioramenti degni di nota:

Fix della connection string MongoDB — lo slash prima del nome del database ora viene gestito correttamente. Se avevate un workaround, potete rimuoverlo
Export SQL Server — Aspire.Hosting.SqlServer ora esporta opzioni di configurazione server aggiuntive per un controllo più granulare
Aggiornamenti emulatori — emulatore ServiceBus 2.0.0, emulatore App Configuration 1.0.2, e l’emulatore preview di CosmosDB ora include un readiness check
Azure Managed Redis — ora usa rediss:// (Redis Secure) di default, quindi le connessioni sono crittografate fin da subito

L’ultimo punto è sottile ma importante — Redis crittografato di default significa una cosa in meno da configurare in produzione.

Per concludere

Aspire 13.2 è una release incrementale, ma le integrazioni MongoDB EF Core e Data Lake colmano lacune reali. Se stavate aspettando un supporto EF Core adeguato con MongoDB in Aspire, o avevate bisogno del Data Lake come dipendenza di prima classe, aggiornate alla 13.2 e provatele. Il comando aspire add genera tutto il necessario.

Leggete le note di rilascio complete per maggiori dettagli, e date un’occhiata alla galleria delle integrazioni per la lista completa.

azd update — Un solo comando per tutti i tuoi package manager

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

Conosci quel messaggio “È disponibile una nuova versione di azd” che compare ogni poche settimane? Quello che ignori perché non ricordi se hai installato azd tramite winget, Homebrew o quello script curl che hai eseguito sei mesi fa? Ecco, finalmente è stato risolto.

Microsoft ha appena rilasciato azd update — un unico comando che aggiorna Azure Developer CLI all’ultima versione indipendentemente da come lo hai installato in origine. Windows, macOS, Linux — non importa. Un solo comando.

Come funziona

azd update

Tutto qui. Se vuoi accesso anticipato alle nuove funzionalità, puoi passare alla build giornaliera insiders:

azd update --channel daily
azd update --channel stable

Il comando rileva il tuo metodo di installazione attuale e utilizza il meccanismo di aggiornamento appropriato dietro le quinte. Niente più “aspetta, ho usato winget o choco su questa macchina?”

Il piccolo dettaglio

azd update è disponibile a partire dalla versione 1.23.x. Se sei su una versione precedente, dovrai fare un ultimo aggiornamento manuale usando il tuo metodo di installazione originale. Dopo di che, azd update gestisce tutto d’ora in avanti.

Controlla la tua versione attuale con azd version. Se hai bisogno di un’installazione da zero, la documentazione di installazione fa al caso tuo.

Perché è importante

È un piccolo miglioramento della qualità della vita, ma per chi di noi usa azd quotidianamente per il deploy di agenti IA e app Aspire su Azure, essere aggiornati significa meno momenti “questo bug era già stato corretto nell’ultima versione”. Una cosa in meno a cui pensare.

Leggi l’annuncio completo e l’approfondimento di Jon Gallant per maggiori dettagli.

Azure DevOps Server Patch Aprile 2026 — Fix per il Completamento delle PR e Aggiornamenti di Sicurezza

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

Avviso rapido per i team che eseguono Azure DevOps Server in self-hosting: Microsoft ha rilasciato la Patch 3 di aprile 2026 con tre fix mirati.

Cosa è stato corretto

Fallimenti nel completamento delle pull request — un’eccezione di riferimento null durante l’auto-completamento dei work item poteva causare il fallimento dei merge delle PR. Se hai riscontrato errori casuali nel completamento delle PR, questa è probabilmente la causa
Validazione del redirect al logout — validazione migliorata durante il logout per prevenire potenziali redirect malevoli. Questo è un fix di sicurezza che vale la pena applicare tempestivamente
Connessioni PAT con GitHub Enterprise Server — la creazione di connessioni con Personal Access Token verso GitHub Enterprise Server era rotta, ora è stata ripristinata

Come aggiornare

Scarica la Patch 3 e avvia l’installer. Per verificare che la patch sia stata applicata:

<patch-installer>.exe CheckInstall

Se esegui Azure DevOps Server on-premises, Microsoft raccomanda fortemente di restare sempre sull’ultima patch sia per sicurezza che per affidabilità. Consulta le note di rilascio per tutti i dettagli.

Azure Smart Tier è in GA — Ottimizzazione automatica dei costi di Blob Storage senza regole di ciclo di vita

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

Se hai mai passato tempo a ottimizzare le policy di ciclo di vita di Azure Blob Storage per poi vederle crollare quando i pattern di accesso sono cambiati, questo è per te. Microsoft ha appena annunciato la disponibilità generale dello smart tier per Azure Blob e Data Lake Storage — una funzionalità di tiering completamente gestita che sposta automaticamente gli oggetti tra i livelli hot, cool e cold in base all’utilizzo reale.

Cosa fa realmente lo smart tier

Il concetto è semplice: lo smart tier valuta continuamente l’ultimo orario di accesso di ogni oggetto nel tuo account di archiviazione. I dati acceduti frequentemente restano in hot, i dati inattivi passano a cool dopo 30 giorni, e poi a cold dopo altri 60 giorni. Quando i dati vengono nuovamente acceduti, vengono promossi subito a hot. Il ciclo ricomincia.

Nessuna regola di ciclo di vita da configurare. Nessuna previsione dei pattern di accesso. Nessun tuning manuale.

Durante la preview, Microsoft ha riportato che oltre il 50% della capacità gestita dallo smart tier si è spostata automaticamente verso livelli più freddi in base ai pattern di accesso reali. È una riduzione dei costi significativa per account di archiviazione di grandi dimensioni.

Perché è importante per gli sviluppatori .NET

Se stai costruendo applicazioni che generano log, telemetria, dati analitici, o qualsiasi tipo di patrimonio dati in crescita — e siamo onesti, chi non lo fa? — i costi di archiviazione si accumulano velocemente. L’approccio tradizionale era scrivere policy di gestione del ciclo di vita, testarle e poi ricalibrarle quando i pattern di accesso della tua applicazione cambiavano. Lo smart tier elimina completamente quel workflow.

Alcuni scenari pratici dove questo aiuta:

Telemetria e log delle applicazioni — hot durante il debug, raramente acceduti dopo qualche settimana
Pipeline di dati e output ETL — acceduti intensamente durante l’elaborazione, poi per lo più cold
Contenuti generati dagli utenti — gli upload recenti sono hot, i contenuti più vecchi si raffreddano gradualmente
Dati di backup e archiviazione — acceduti occasionalmente per conformità, per lo più inattivi

Come configurarlo

Abilitare lo smart tier è una configurazione una tantum:

Account nuovi: Seleziona smart tier come livello di accesso predefinito durante la creazione dell’account di archiviazione (ridondanza zonale richiesta)
Account esistenti: Cambia il livello di accesso blob dall’impostazione predefinita attuale a smart tier

Gli oggetti più piccoli di 128 KiB restano in hot e non generano la tariffa di monitoraggio. Per tutto il resto, paghi le tariffe standard di capacità hot/cool/cold senza costi di transizione tra livelli, senza penali per eliminazione anticipata e senza costi di recupero dati. Una tariffa mensile di monitoraggio per oggetto copre l’orchestrazione.

Il compromesso da conoscere

Le regole di tiering dello smart tier sono statiche (30 giorni → cool, 90 giorni → cold). Se hai bisogno di soglie personalizzate — ad esempio, spostare a cool dopo 7 giorni per un workload specifico — le regole di ciclo di vita restano la strada giusta. E non mescolare entrambi: evita di usare regole di ciclo di vita su oggetti gestiti dallo smart tier, perché possono entrare in conflitto.

Conclusione

Non è rivoluzionario, ma risolve un vero grattacapo operativo. Se gestisci account di blob storage in crescita e sei stanco di mantenere le policy di ciclo di vita, abilita lo smart tier e lascia che Azure se ne occupi. È disponibile oggi in quasi tutte le regioni zonali del cloud pubblico.

Dove dovresti ospitare i tuoi agenti IA su Azure? Una guida decisionale pratica

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

Se stai costruendo agenti IA con .NET in questo momento, probabilmente hai notato qualcosa: ci sono molti modi per ospitarli su Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — e tutti sembrano ragionevoli finché non devi effettivamente sceglierne uno. Microsoft ha appena pubblicato una guida completa all’hosting di agenti IA su Azure che chiarisce tutto, e voglio analizzarla dalla prospettiva pratica di uno sviluppatore .NET.

Le sei opzioni a colpo d’occhio

Ecco come riassumerei il panorama:

Opzione	Ideale per	Gestisci tu
Container Apps	Controllo totale dei container senza complessità K8s	Osservabilità, stato, ciclo di vita
AKS	Compliance aziendale, multi-cluster, networking personalizzato	Tutto (è quello il punto)
Azure Functions	Task di agenti event-driven e di breve durata	Quasi niente — serverless vero
App Service	Agenti HTTP semplici, traffico prevedibile	Deploy, config di scaling
Foundry Agents	Agenti senza codice via portale/SDK	Quasi niente
Foundry Hosted Agents	Agenti con framework personalizzato e infra gestita	Solo il tuo codice agente

Le prime quattro sono compute general-purpose — puoi eseguire agenti su di esse, ma non sono state progettate per quello. Le ultime due sono native per agenti: comprendono conversazioni, chiamate a strumenti e cicli di vita degli agenti come concetti di prima classe.

Foundry Hosted Agents — il punto ideale per sviluppatori .NET di agenti

Questo è ciò che ha catturato la mia attenzione. I Foundry Hosted Agents si posizionano proprio nel mezzo: ottieni la flessibilità di eseguire il tuo codice (Semantic Kernel, Agent Framework, LangGraph — qualsiasi cosa) ma la piattaforma gestisce infrastruttura, osservabilità e gestione delle conversazioni.

Il pezzo chiave è l’Hosting Adapter — un sottile livello di astrazione che collega il tuo framework di agenti alla piattaforma Foundry. Per Microsoft Agent Framework, appare così:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Questa è tutta la tua storia di hosting. L’adapter gestisce traduzione di protocolli, streaming via server-sent events, cronologia delle conversazioni e tracing OpenTelemetry — tutto automaticamente. Nessun middleware personalizzato, nessun plumbing manuale.

Il deploy è genuinamente semplice

Ho fatto deploy di agenti su Container Apps prima e funziona, ma finisci per scrivere molto codice di collegamento per gestione dello stato e osservabilità. Con Hosted Agents e azd, il deploy è:

# Installare l'estensione agente IA
azd ext install azure.ai.agents

# Inizializzare da un template
azd ai agent init

# Costruire, pushare, fare deploy — fatto
azd up

Quel singolo azd up costruisce il tuo container, lo pusha su ACR, provisiona il progetto Foundry, fa deploy degli endpoint del modello e avvia il tuo agente. Cinque passaggi condensati in un solo comando.

Gestione conversazioni integrata

Questa è la parte che fa risparmiare più tempo in produzione. Invece di costruire il tuo store di stato delle conversazioni, gli Hosted Agents lo gestiscono nativamente:

# Creare una conversazione persistente
conversation = openai_client.conversations.create()

# Primo turno
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Secondo turno — il contesto è preservato
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Niente Redis. Niente session store Cosmos DB. Niente middleware personalizzato per la serializzazione dei messaggi. La piattaforma semplicemente se ne occupa.

Il mio framework decisionale

Dopo aver esaminato tutte e sei le opzioni, ecco il mio modello mentale rapido:

Hai bisogno di zero infrastruttura? → Foundry Agents (portale/SDK, niente container)
Hai codice agente personalizzato ma vuoi hosting gestito? → Foundry Hosted Agents
Hai bisogno di task agente event-driven e di breve durata? → Azure Functions
Hai bisogno di massimo controllo dei container senza K8s? → Container Apps
Hai bisogno di compliance rigorosa e multi-cluster? → AKS
Hai un agente HTTP semplice con traffico prevedibile? → App Service

Per la maggior parte degli sviluppatori .NET che costruiscono con Semantic Kernel o Microsoft Agent Framework, Hosted Agents è probabilmente il punto di partenza giusto. Ottieni scale-to-zero, OpenTelemetry integrato, gestione conversazioni e flessibilità di framework — senza gestire Kubernetes o montare il tuo stack di osservabilità.

Per concludere

Il panorama dell’hosting di agenti su Azure sta maturando velocemente. Se stai iniziando un nuovo progetto di agente IA oggi, considererei seriamente Foundry Hosted Agents prima di ricorrere a Container Apps o AKS per abitudine. L’infrastruttura gestita fa risparmiare tempo reale, e il pattern hosting adapter ti permette di mantenere la tua scelta di framework.

Dai un’occhiata alla guida completa di Microsoft e al repo Foundry Samples per esempi funzionanti.

Le Agent Skills in .NET sono diventate davvero flessibili

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Se avete costruito agenti con il Microsoft Agent Framework, conoscete il processo: definite le skill, le collegate a un provider e lasciate che l’agente decida quale invocare. La novità è come create queste skill — e il salto in flessibilità è significativo.

L’ultimo aggiornamento introduce tre pattern di authoring per le agent skill: basate su file, basate su classi e definite in codice inline. Tutte e tre si collegano a un unico AgentSkillsProviderBuilder, il che significa che potete mescolarle senza logica di routing o codice speciale. Vi mostro ciascuna e quando usarla.

Skill basate su file: il punto di partenza

Le skill basate su file sono esattamente quello che sembrano — una directory su disco con un file SKILL.md, script opzionali e documenti di riferimento. Il modo più diretto per dare nuove capacità al vostro agente:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

Il frontmatter di SKILL.md dichiara il nome e la descrizione, e la sezione istruzioni dice all’agente come usare script e riferimenti:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Poi lo collegate con SubprocessScriptRunner.RunAsync per l’esecuzione degli script:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

L’agente scopre la skill automaticamente e invoca lo script di provisioning quando deve verificare lo stato degli account. Pulito e semplice.

Skill basate su classi: distribuire via NuGet

Qui diventa interessante per i team. Le skill basate su classi derivano da AgentClassSkill<T> e usano attributi come [AgentSkillResource] e [AgentSkillScript] perché il framework scopra tutto tramite reflection:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Il bello è che un team può impacchettarlo come pacchetto NuGet. Lo aggiungete al progetto, lo inserite nel builder e funziona accanto alle vostre skill basate su file senza coordinazione:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Entrambe le skill appaiono nel system prompt dell’agente. L’agente decide quale usare in base alla conversazione — nessun codice di routing necessario.

Skill inline: il ponte rapido

Conoscete quel momento in cui un altro team sta costruendo esattamente la skill di cui avete bisogno, ma non sarà pronta fino al prossimo sprint? AgentInlineSkill è il vostro ponte:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Aggiungetela al builder come le altre:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Quando il pacchetto NuGet esce finalmente, sostituite la skill inline con la versione basata su classe. L’agente non nota la differenza.

Ma le skill inline non sono solo per i ponti. Sono anche la scelta giusta quando dovete generare skill dinamicamente a runtime — pensate a una skill per unità di business caricata dalla configurazione — o quando uno script deve catturare stato locale che non appartiene a un container DI.

Approvazione degli script: umano nel loop

Per noi sviluppatori .NET che costruiamo agenti di produzione, questa è la parte che sblocca davvero le discussioni sul deployment. Alcuni script hanno conseguenze reali — iscrivere qualcuno ai benefit, interrogare l’infrastruttura di produzione. Attivate UseScriptApproval e l’agente si ferma prima di eseguire qualsiasi script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Quando l’agente vuole eseguire uno script, restituisce una richiesta di approvazione. La vostra app raccoglie la decisione — approvare o rifiutare — e l’agente continua di conseguenza. Negli ambienti regolamentati, questa è la differenza tra “possiamo fare il deploy” e “l’ufficio legale dice no.”

Perché questa combinazione conta

Il vero potere non è in nessun pattern individuale — è nella composizione. Potete:

Iniziare in piccolo con una skill basata su file, iterare sulle istruzioni e pubblicarla senza scrivere C#
Distribuire skill riutilizzabili come pacchetti NuGet che altri team aggiungono con una riga
Colmare lacune con skill inline quando avete bisogno di qualcosa adesso
Filtrare directory condivise con predicati perché il vostro agente carichi solo quello che deve
Aggiungere supervisione umana per gli script che toccano sistemi di produzione

Tutto questo si compone tramite AgentSkillsProviderBuilder. Nessun routing speciale, nessuna logica condizionale, nessun controllo del tipo di skill.

Per concludere

Le agent skill in .NET ora hanno un modello di authoring genuinamente flessibile. Che siate uno sviluppatore solo che prototipa con skill basate su file o un team enterprise che distribuisce capacità impacchettate via NuGet, i pattern si adattano. E il meccanismo di approvazione degli script lo rende pronto per la produzione negli ambienti dove serve quel checkpoint umano.

Date un’occhiata all’annuncio originale, alla documentazione Agent Skills su Microsoft Learn e agli esempi .NET su GitHub per iniziare.

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.

Costruire UI Multi-Agente in Tempo Reale Che Non Sembrino una Scatola Nera

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

Ecco il punto dei sistemi multi-agente: nelle demo sono incredibili. Tre agenti che si passano il lavoro, risolvono problemi, prendono decisioni. Poi provi a metterlo davanti a utenti reali e… silenzio. Un indicatore che gira. Nessuna idea di quale agente stia facendo cosa o perché il sistema sia in pausa. Quello non è un prodotto — è un problema di fiducia.

Il team di Microsoft Agent Framework ha appena pubblicato un fantastico walkthrough su come accoppiare i workflow MAF con AG-UI, un protocollo aperto per lo streaming degli eventi di esecuzione degli agenti verso un frontend tramite Server-Sent Events. E onestamente? È esattamente il ponte che ci mancava.

Perché questo è importante per gli sviluppatori .NET

Se stai costruendo app alimentate dall’IA, probabilmente hai già sbattuto contro questo muro. La tua orchestrazione backend funziona benissimo — gli agenti si passano il lavoro, gli strumenti si attivano, le decisioni vengono prese. Ma il frontend non ha idea di cosa stia succedendo dietro le quinte. AG-UI risolve questo definendo un protocollo standard per lo streaming degli eventi degli agenti (pensa a RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) direttamente verso il tuo layer UI tramite SSE.

La demo è un workflow di supporto clienti con tre agenti: un agente di triage che smista le richieste, un agente rimborsi che gestisce le questioni di denaro, e un agente ordini che gestisce le sostituzioni. Ogni agente ha i propri strumenti, e la topologia di handoff è definita esplicitamente — niente “scoprilo dal prompt”.

La topologia di handoff è la vera star

Quello che mi ha colpito è come HandoffBuilder ti permette di dichiarare un grafo di routing diretto tra gli agenti:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Ogni add_handoff crea un arco diretto con una descrizione in linguaggio naturale. Il framework genera strumenti di handoff per ogni agente basandosi su questa topologia. Quindi le decisioni di routing sono fondate sulla tua struttura di orchestrazione, non solo su quello che il LLM decide di fare. Questo è un vantaggio enorme per l’affidabilità in produzione.

Human-in-the-loop che funziona davvero

La demo mostra due pattern di interruzione di cui qualsiasi app di agenti reale ha bisogno:

Interruzioni di approvazione strumenti — quando un agente chiama uno strumento marcato con approval_mode="always_require", il workflow si mette in pausa ed emette un evento. Il frontend mostra un modal di approvazione con il nome dello strumento e i suoi argomenti. Niente loop di retry che bruciano token — solo un flusso pulito pausa-approvazione-ripresa.

Interruzioni di richiesta informazioni — quando un agente ha bisogno di più contesto dall’utente (come un ID ordine), si mette in pausa e chiede. Il frontend mostra la domanda, l’utente risponde, e l’esecuzione riprende esattamente da dove si era fermata.

Entrambi i pattern vengono trasmessi come eventi AG-UI standard, quindi il tuo frontend non ha bisogno di logica personalizzata per agente — semplicemente renderizza qualsiasi evento arrivi dalla connessione SSE.

Collegare il tutto è sorprendentemente semplice

L’integrazione tra MAF e AG-UI si riduce a una singola chiamata di funzione:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

La workflow_factory crea un workflow fresco per thread, così ogni conversazione ottiene il proprio stato isolato. L’endpoint gestisce tutta l’infrastruttura SSE automaticamente. Se stai già usando FastAPI (o puoi aggiungerlo come layer leggero), c’è praticamente zero frizione.

La mia opinione

Per noi sviluppatori .NET, la domanda immediata è: “Posso farlo in C#?” L’Agent Framework è disponibile sia per .NET che per Python, e il protocollo AG-UI è agnostico rispetto al linguaggio (è solo SSE). Quindi anche se questa demo specifica usa Python e FastAPI, il pattern si traduce direttamente. Potresti configurare una API minimale ASP.NET Core con endpoint SSE seguendo lo stesso schema di eventi AG-UI.

Il messaggio più importante è che le UI multi-agente stanno diventando una preoccupazione di prima classe, non un ripensamento. Se stai costruendo qualcosa dove gli agenti interagiscono con gli umani — supporto clienti, workflow di approvazione, elaborazione documenti — questa combinazione di orchestrazione MAF e trasparenza AG-UI è il pattern da seguire.

Per concludere

AG-UI + Microsoft Agent Framework ti dà il meglio di entrambi i mondi: orchestrazione multi-agente robusta nel backend e visibilità in tempo reale nel frontend. Niente più interazioni tra agenti come scatole nere.

Dai un’occhiata al walkthrough completo e al repository del protocollo AG-UI per approfondire.

L'Ingegneria delle Piattaforme Agentiche Sta Diventando Realtà — Git-APE Mostra Come

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

L’ingegneria delle piattaforme è stato uno di quei termini che suona bene alle conferenze ma che di solito significa “abbiamo costruito un portale interno e un wrapper Terraform.” La vera promessa — infrastruttura self-service che sia realmente sicura, governata e veloce — è sempre stata a qualche passo di distanza.

Il team Azure ha appena pubblicato la Parte 2 della serie sull’ingegneria delle piattaforme agentiche, e questa è tutta sull’implementazione pratica. Lo chiamano Git-APE (sì, l’acronimo è intenzionale), ed è un progetto open source che utilizza agenti GitHub Copilot più server Azure MCP per trasformare richieste in linguaggio naturale in infrastruttura validata e deployata.

Cosa fa Git-APE concretamente

L’idea centrale: invece di far imparare ai developer moduli Terraform, navigare nelle UI dei portali o aprire ticket al team piattaforma, parlano con un agente Copilot. L’agente interpreta l’intento, genera Infrastructure-as-Code, la valida contro le policy e deploya — tutto all’interno di VS Code.

Ecco il setup:

git clone https://github.com/Azure/git-ape
cd git-ape

Apri il workspace in VS Code, e i file di configurazione dell’agente vengono scoperti automaticamente da GitHub Copilot. Interagisci direttamente con l’agente:

@git-ape deploy a function app with storage in West Europe

L’agente utilizza Azure MCP Server internamente per interagire con i servizi Azure. La configurazione MCP nelle impostazioni di VS Code abilita capacità specifiche:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Perché è importante

Per chi di noi costruisce su Azure, questo sposta la conversazione sull’ingegneria delle piattaforme da “come costruiamo un portale” a “come descriviamo i nostri guardrail come API.” Quando l’interfaccia della tua piattaforma è un agente IA, la qualità dei tuoi vincoli e delle tue policy diventa il prodotto.

Il blog della Parte 1 esponeva la teoria: API ben descritte, schemi di controllo e guardrail espliciti rendono le piattaforme agent-ready. La Parte 2 dimostra che funziona rilasciando strumenti concreti. L’agente non genera risorse alla cieca — valida contro le best practice, rispetta le convenzioni di naming e applica le policy della tua organizzazione.

La pulizia è altrettanto semplice:

@git-ape destroy my-resource-group

La mia opinione

Sarò onesto — qui si tratta più del pattern che dello strumento specifico. Git-APE in sé è una demo/architettura di riferimento. Ma l’idea sottostante — agenti come interfaccia alla tua piattaforma, MCP come protocollo, GitHub Copilot come host — è la direzione in cui sta andando l’esperienza developer enterprise.

Se sei un team piattaforma che cerca come rendere il proprio tooling interno agent-friendly, non c’è punto di partenza migliore. E se sei uno sviluppatore .NET che si chiede come questo si collega al suo mondo: Azure MCP Server e gli agenti GitHub Copilot funzionano con qualsiasi workload Azure. La tua API ASP.NET Core, il tuo stack .NET Aspire, i tuoi microservizi containerizzati — tutto può essere il target di un flusso di deployment agentico.

Per concludere

Git-APE è uno sguardo precoce ma concreto sull’ingegneria delle piattaforme agentiche nella pratica. Clona il repo, prova la demo e inizia a pensare a come le API e le policy della tua piattaforma dovrebbero apparire per permettere a un agente di usarle in sicurezza.

Leggi il post completo per il walkthrough e i video dimostrativi.

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.

Microsoft Foundry Marzo 2026 — GPT-5.4, Agent Service GA e il Refresh dell'SDK Che Cambia Tutto

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

I post mensili “Novità in Microsoft Foundry” sono solitamente un mix di miglioramenti incrementali e occasionali funzionalità di rilievo. L’edizione di marzo 2026? Praticamente tutte funzionalità di rilievo. Foundry Agent Service raggiunge la GA, GPT-5.4 arriva in produzione, l’SDK riceve un importante rilascio stabile, e Fireworks AI porta l’inferenza di modelli aperti su Azure. Vediamo cosa conta per gli sviluppatori .NET.

Foundry Agent Service è pronto per la produzione

Questa è la grande notizia. Il runtime di agenti di nuova generazione è generalmente disponibile — costruito sull’API Responses di OpenAI, compatibile a livello di protocollo con gli agenti OpenAI, e aperto a modelli di diversi provider. Se state costruendo con l’API Responses oggi, migrare a Foundry aggiunge sicurezza enterprise, networking privato, RBAC di Entra, tracing completo e valutazione sulla vostra logica di agenti esistente.

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

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

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.",
 ),
)

Aggiunte chiave: networking privato end-to-end, espansione dell’autenticazione MCP (incluso il passthrough OAuth), anteprima di Voice Live per agenti voce-a-voce, e agenti ospitati in 6 nuove regioni.

GPT-5.4 — affidabilità oltre l’intelligenza pura

GPT-5.4 non riguarda l’essere più intelligente. Riguarda l’essere più affidabile. Ragionamento più solido nelle interazioni lunghe, migliore aderenza alle istruzioni, meno fallimenti a metà workflow, e capacità integrate di computer use. Per gli agenti in produzione, quell’affidabilità conta molto più dei punteggi nei benchmark.

Modello	Prezzo (per M token)	Ideale Per
GPT-5.4 (≤272K)	$2.50 / $15 output	Agenti in produzione, coding, workflow documentali
GPT-5.4 Pro	$30 / $180 output	Analisi approfondita, ragionamento scientifico
GPT-5.4 Mini	Economico	Classificazione, estrazione, chiamate leggere a strumenti

La mossa intelligente è una strategia di routing: GPT-5.4 Mini gestisce il lavoro ad alto volume e bassa latenza mentre GPT-5.4 si occupa delle richieste con ragionamento pesante.

L’SDK è finalmente stabile

L’SDK azure-ai-projects ha rilasciato versioni stabili in tutti i linguaggi — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, e .NET 2.0.0 (1 aprile). La dipendenza da azure-ai-agents è sparita — tutto vive sotto AIProjectClient. Installate con pip install azure-ai-projects e il pacchetto include openai e azure-identity come dipendenze dirette.

Per gli sviluppatori .NET, questo significa un singolo pacchetto NuGet per l’intera superficie di Foundry. Basta destreggiarsi tra SDK di agenti separati.

Fireworks AI porta i modelli aperti su Azure

Forse l’aggiunta più interessante dal punto di vista architetturale: Fireworks AI elabora oltre 13 trilioni di token al giorno a ~180K richieste/secondo, ora disponibile tramite Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, e MiniMax M2.5 al lancio.

La vera storia è il bring-your-own-weights — caricate pesi quantizzati o fine-tunati da qualsiasi luogo senza cambiare lo stack di serving. Deploy tramite serverless pay-per-token o throughput provisionato.

Altri punti salienti

Phi-4 Reasoning Vision 15B — ragionamento multimodale per grafici, diagrammi e layout di documenti
Evaluations GA — valutatori pronti all’uso con monitoraggio continuo della produzione integrato in Azure Monitor
Priority Processing (Preview) — corsia di calcolo dedicata per carichi di lavoro sensibili alla latenza
Voice Live — runtime voce-a-voce che si connette direttamente agli agenti Foundry
Tracing GA — ispezione end-to-end delle tracce degli agenti con ordinamento e filtraggio
Deprecazione di PromptFlow — migrazione a Microsoft Framework Workflows entro gennaio 2027

Conclusione

Marzo 2026 è un punto di svolta per Foundry. Agent Service GA, SDK stabili in tutti i linguaggi, GPT-5.4 per agenti di produzione affidabili, e inferenza di modelli aperti via Fireworks AI — la piattaforma è pronta per carichi di lavoro seri.

Leggete il riepilogo completo e create il vostro primo agente per iniziare.

Quell'Impostazione delle Finestre Flottanti di Visual Studio Che Non Conoscevi (Ma Dovresti)

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

Se usate più monitor con Visual Studio (e onestamente, chi non lo fa al giorno d’oggi?), probabilmente avete sperimentato la frustrazione: le finestre degli strumenti flottanti scompaiono quando minimizzate l’IDE principale, restano sempre sopra a tutto il resto, e non appaiono come pulsanti separati nella barra delle applicazioni. Funziona per alcuni workflow, ma per configurazioni multi-monitor è frustrante.

Mads Kristensen del team di Visual Studio ha condiviso un’impostazione poco conosciuta che cambia completamente il comportamento delle finestre flottanti. Un menu a tendina. Tutto qui.

L’impostazione

Tools > Options > Environment > Windows > Floating Windows

Il menu a tendina “These floating windows are owned by the main window” ha tre opzioni:

None — indipendenza totale. Ogni finestra flottante ha la propria voce nella barra delle applicazioni e si comporta come una normale finestra di Windows.
Tool Windows (predefinito) — i documenti flottano liberamente, le finestre degli strumenti restano legate all’IDE.
Documents and Tool Windows — comportamento classico di Visual Studio, tutto legato alla finestra principale.

Perché “None” è la scelta giusta per configurazioni multi-monitor

Impostatelo su None e improvvisamente tutte le vostre finestre flottanti di strumenti e documenti si comportano come vere applicazioni Windows. Appaiono nella barra delle applicazioni, restano visibili quando minimizzate la finestra principale di Visual Studio, e smettono di forzarsi in primo piano.

Combinatelo con PowerToys FancyZones ed è un vero game changer. Create layout personalizzati sui vostri monitor, agganciate l’Esplora Soluzioni in una zona, il debugger in un’altra, e i file di codice dove volete. Tutto resta al suo posto, tutto è accessibile indipendentemente, e il vostro spazio di lavoro risulta organizzato invece che caotico.

Raccomandazioni rapide

Utenti avanzati multi-monitor: Impostate su None, abbinate con FancyZones
Utenti occasionali delle finestre flottanti: Tool Windows (predefinito) è un buon compromesso
Workflow tradizionale: Documents and Tool Windows mantiene tutto classico

Consiglio pro: Ctrl + doppio clic sulla barra del titolo di qualsiasi finestra degli strumenti per renderla flottante o agganciarla istantaneamente. Non serve riavviare dopo aver cambiato l’impostazione.

Conclusione

È una di quelle impostazioni del tipo “non ci posso credere che non lo sapevo”. Se le finestre flottanti in Visual Studio vi hanno mai infastidito, andate a cambiare questa impostazione adesso.

Leggete il post completo per i dettagli e gli screenshot.

SQL MCP Server — Il modo giusto per dare accesso ai database agli agenti AI

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

Siamo onesti: la maggior parte dei server MCP per database disponibili oggi sono spaventosi. Prendono una query in linguaggio naturale, generano SQL al volo e lo eseguono contro i tuoi dati di produzione. Cosa potrebbe andare storto? (Tutto. Tutto potrebbe andare storto.)

Il team di Azure SQL ha appena presentato SQL MCP Server, e adotta un approccio fondamentalmente diverso. Costruito come funzionalità di Data API builder (DAB) 2.0, dà agli agenti AI un accesso strutturato e deterministico alle operazioni sul database — senza NL2SQL, senza esporre il tuo schema, e con RBAC completo ad ogni passaggio.

Perché non NL2SQL?

Questa è la decisione di design più interessante. I modelli non sono deterministici, e le query complesse sono le più propense a produrre errori sottili. Le query esatte che gli utenti sperano che l’AI possa generare sono anche quelle che richiedono più scrutinio quando prodotte in modo non deterministico.

Invece, SQL MCP Server usa un approccio NL2DAB. L’agente lavora con il livello di astrazione delle entità di Data API builder e il suo query builder integrato per produrre T-SQL accurato e ben formato in modo deterministico. Stesso risultato per l’utente, ma senza il rischio di JOIN allucinati o esposizione accidentale di dati.

Sette strumenti, non settecento

SQL MCP Server espone esattamente sette strumenti DML, indipendentemente dalle dimensioni del database:

describe_entities — scoprire entità e operazioni disponibili
create_record — inserire righe
read_records — interrogare tabelle e viste
update_record — modificare righe
delete_record — rimuovere righe
execute_entity — eseguire stored procedure
aggregate_records — query di aggregazione

Questo è intelligente perché le finestre di contesto sono lo spazio di pensiero dell’agente. Inondarle con centinaia di definizioni di strumenti lascia meno spazio per il ragionamento. Sette strumenti fissi mantengono l’agente concentrato sul pensare piuttosto che sul navigare.

Ogni strumento può essere abilitato o disabilitato individualmente:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Iniziare in tre comandi

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Ecco un SQL MCP Server funzionante che espone la tua tabella Customers. Il livello di astrazione delle entità significa che puoi creare alias per nomi e colonne, limitare i campi per ruolo e controllare esattamente cosa vedono gli agenti — senza esporre dettagli interni dello schema.

La storia della sicurezza è solida

Qui è dove la maturità di Data API builder ripaga:

RBAC ad ogni livello — ogni entità definisce quali ruoli possono leggere, creare, aggiornare o eliminare, e quali campi sono visibili
Integrazione con Azure Key Vault — stringhe di connessione e segreti gestiti in modo sicuro
Microsoft Entra + OAuth personalizzato — autenticazione di livello produzione
Content Security Policy — gli agenti interagiscono attraverso un contratto controllato, non SQL grezzo

L’astrazione dello schema è particolarmente importante. I nomi interni delle tue tabelle e colonne non vengono mai esposti all’agente. Definisci entità, alias e descrizioni che hanno senso per l’interazione AI — non il tuo diagramma ERD del database.

Multi-database e multi-protocollo

SQL MCP Server supporta Microsoft SQL, PostgreSQL, Azure Cosmos DB e MySQL. E poiché è una funzionalità di DAB, ottieni endpoint REST, GraphQL e MCP simultaneamente dalla stessa configurazione. Stesse definizioni di entità, stesse regole RBAC, stessa sicurezza — su tutti e tre i protocolli.

L’auto-configurazione in DAB 2.0 può persino ispezionare il tuo database e costruire la configurazione dinamicamente, se sei a tuo agio con meno astrazione per la prototipazione rapida.

La mia opinione

Ecco come dovrebbe funzionare l’accesso aziendale ai database per gli agenti AI. Non “hey LLM, scrivimi un po’ di SQL e YOLO sulla produzione.” Invece: un livello di entità ben definito, generazione deterministica delle query, RBAC ad ogni passaggio, caching, monitoraggio e telemetria. È noioso nel miglior modo possibile.

Per gli sviluppatori .NET, la storia dell’integrazione è pulita — DAB è uno strumento .NET, l’MCP Server gira come container, e funziona con Azure SQL, che la maggior parte di noi sta già usando. Se stai costruendo agenti AI che hanno bisogno di accesso ai dati, inizia qui.

Conclusione

SQL MCP Server è gratuito, open-source e gira ovunque. È l’approccio prescrittivo di Microsoft per dare agli agenti AI un accesso sicuro ai database. Consulta il post completo e la documentazione per iniziare.

VS Code 1.116 — L'App Agents Ottiene Navigazione da Tastiera e Completamenti per il Contesto dei File

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

VS Code 1.116 è il rilascio di aprile 2026, e sebbene sia più leggero di alcuni aggiornamenti recenti, i cambiamenti sono mirati e significativi — specialmente se usate l’app Agents quotidianamente.

Ecco cosa è arrivato, in base alle note di rilascio ufficiali.

Miglioramenti dell’app Agents

L’app Agents continua a maturare con un polishing dell’usabilità che fa una vera differenza nei flussi di lavoro quotidiani:

Scorciatoie da tastiera dedicate — ora potete mettere a fuoco la vista Changes, l’albero dei file all’interno di Changes e la vista delle Personalizzazioni della Chat con comandi e scorciatoie da tastiera dedicati. Se cliccavate ovunque nell’app Agents per navigare, questo porta flussi di lavoro completamente controllabili da tastiera.

Dialogo di aiuto per l’accessibilità — premere Alt+F1 nella casella di input della chat ora apre un dialogo di aiuto per l’accessibilità che mostra i comandi e le scorciatoie disponibili. Gli utenti di screen reader possono anche controllare la verbosità degli annunci. Una buona accessibilità beneficia tutti.

Completamenti per il contesto dei file — digitate # nella chat dell’app Agents per attivare i completamenti per il contesto dei file limitati al vostro workspace corrente. Questa è una di quelle piccole migliorie della qualità della vita che velocizzano ogni interazione — niente più percorsi completi dei file quando si referenzia il codice.

Risoluzione dei link CSS `@import`

Ottimo per gli sviluppatori frontend: VS Code ora risolve i riferimenti CSS @import che usano percorsi di node_modules. Potete fare Ctrl+clic attraverso import come @import "some-module/style.css" quando usate bundler. Piccolo ma elimina un punto di attrito nei workflow CSS.

Conclusione

VS Code 1.116 riguarda il raffinamento — rendere l’app Agents più navigabile, più accessibile e più amichevole con la tastiera. Se passate molto tempo nell’app Agents (e sospetto che molti di noi lo facciano), questi cambiamenti si sommano.

Consultate le note di rilascio complete per l’elenco completo.

VS Code 1.115 — Notifiche del Terminale in Background, Modalità Agente SSH e Altro

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 è appena uscito, e sebbene sia un rilascio più leggero in termini di funzionalità principali, i miglioramenti relativi agli agenti sono genuinamente utili se lavori quotidianamente con assistenti di codice basati su IA.

Lasciami evidenziare cosa vale davvero la pena sapere.

I terminali in background comunicano con gli agenti

Questa è la funzionalità di punta. I terminali in background ora notificano automaticamente gli agenti quando i comandi vengono completati, inclusi il codice di uscita e l’output del terminale. I prompt di input nei terminali in background vengono anche rilevati e mostrati all’utente.

Perché è importante? Se hai usato la modalità agente di Copilot per eseguire comandi di build o suite di test in background, conosci il dolore del “ma è già finito?” — i terminali in background erano essenzialmente spara-e-dimentica. Ora l’agente viene notificato quando il tuo dotnet build o dotnet test è completato, vede l’output e può reagire di conseguenza. È un piccolo cambiamento che rende i flussi di lavoro guidati dagli agenti significativamente più affidabili.

C’è anche un nuovo strumento send_to_terminal che permette agli agenti di inviare comandi ai terminali in background con conferma dell’utente, risolvendo il problema dove run_in_terminal con un timeout spostava i terminali in background e li rendeva di sola lettura.

Hosting remoto di agenti tramite SSH

VS Code ora supporta la connessione a macchine remote tramite SSH, installando automaticamente la CLI e avviandola in modalità host di agenti. Questo significa che le tue sessioni di agenti IA possono puntare direttamente ad ambienti remoti — utile per gli sviluppatori .NET che compilano e testano su server Linux o VM nel cloud.

Tracciamento delle modifiche nelle sessioni degli agenti

Le modifiche ai file effettuate durante le sessioni degli agenti ora vengono tracciate e ripristinate, con diff, annulla/ripristina e ripristino dello stato. Se un agente apporta modifiche al tuo codice e qualcosa va storto, puoi vedere esattamente cosa è cambiato e fare il rollback. Tranquillità nel lasciare che gli agenti modifichino la tua codebase.

Riconoscimento delle schede del browser e altri miglioramenti

Alcune aggiunte aggiuntive per la qualità della vita:

Tracciamento delle schede del browser — la chat ora può tracciare e collegare le schede del browser aperte durante una sessione, così gli agenti possono fare riferimento alle pagine web che stai guardando
Incolla file nel terminale — incolla file (incluse immagini) nel terminale con Ctrl+V, trascinamento o clic destro
Copertura dei test nella minimap — gli indicatori di copertura dei test ora appaiono nella minimap per una panoramica visiva rapida
Pinch-to-zoom su Mac — il browser integrato supporta i gesti pinch-to-zoom
Diritti Copilot nelle Sessioni — la barra di stato mostra le informazioni di utilizzo nella vista Sessioni
Favicon in Vai al File — le pagine web aperte mostrano le favicon nella lista di selezione rapida

Per concludere

VS Code 1.115 è un rilascio incrementale, ma i miglioramenti degli agenti — notifiche del terminale in background, hosting di agenti SSH e tracciamento delle modifiche — si sommano a un’esperienza notevolmente più fluida per lo sviluppo assistito dall’IA. Se stai usando la modalità agente di Copilot per progetti .NET, questi sono il tipo di miglioramenti di qualità della vita che riducono l’attrito quotidiano.

Dai un’occhiata alle note di rilascio complete per ogni dettaglio.

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.

Azure DevOps finalmente sistema l'editor Markdown di cui tutti si lamentavano

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

Se usi Azure Boards, probabilmente hai vissuto questo: stai leggendo la descrizione di un work item, magari controllando i criteri di accettazione, e fai accidentalmente doppio clic. Boom — sei in modalità modifica. Non volevi modificare niente. Stavi solo leggendo.

Dan Hellem ha annunciato la correzione, ed è uno di quei cambiamenti che sembrano piccoli ma rimuovono vera frizione dal tuo flusso di lavoro quotidiano.

Cosa è cambiato

L’editor Markdown per i campi testo dei work item ora si apre in modalità anteprima di default. Puoi leggere e interagire con il contenuto — seguire link, verificare la formattazione — senza preoccuparti di entrare accidentalmente in modalità modifica.

Quando vuoi davvero modificare, clicchi sull’icona di modifica in cima al campo. Quando hai finito, esci esplicitamente alla modalità anteprima. Semplice, intenzionale, prevedibile.

Perché conta più di quanto sembra

Il thread di feedback della community era lungo. Il comportamento del doppio clic per modificare è stato introdotto con l’editor Markdown a luglio 2025, e le lamentele sono iniziate quasi subito.

Per i team che fanno sprint planning, backlog refinement o code review con Azure Boards, questo tipo di micro-frizione si accumula.

Stato del rollout

È già in fase di distribuzione per un sottoinsieme di clienti e si espanderà a tutti nelle prossime due-tre settimane.

Per concludere

Non ogni miglioramento deve essere una funzionalità da prima pagina. A volte il miglior aggiornamento è semplicemente rimuovere qualcosa di fastidioso. Questo è esattamente così — un piccolo fix UX che rende Azure Boards meno ostile per chi vuole solo leggere i propri work item in pace.

Bookmark Studio porta navigazione a slot e condivisione ai segnalibri di Visual Studio

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

I segnalibri in Visual Studio sono sempre stati… discreti. Ne metti uno, navighi al successivo, dimentichi qual è quale. Funzionano, ma non sono mai stati qualcosa che chiameresti potente.

Mads Kristensen ha appena rilasciato Bookmark Studio, un’estensione sperimentale che colma esattamente le lacune che probabilmente hai incontrato.

Navigazione a slot

I segnalibri possono essere assegnati a slot da 1 a 9 e raggiunti direttamente con Alt+Shift+1 fino a Alt+Shift+9. I nuovi segnalibri ottengono automaticamente il primo slot disponibile.

Il Gestore di Segnalibri

Una nuova finestra strumenti mostra tutti i segnalibri con filtri per nome, file, posizione, colore o slot.

Organizzazione con etichette, colori e cartelle

I segnalibri possono avere etichette, colori ed essere raggruppati in cartelle. I metadati sono salvati per soluzione.

Esporta e condividi

Bookmark Studio permette di esportare segnalibri come testo, Markdown o CSV.

Segnalibri che seguono il codice

Bookmark Studio traccia i segnalibri relativamente al testo ancorato, quindi non si spostano sulle righe sbagliate.

Per concludere

Bookmark Studio non reinventa nulla. Prende una funzionalità che era “sufficiente” da anni e la rende davvero utile. Scaricalo dal Visual Studio Marketplace.

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.

SQL MCP Server, Copilot in SSMS e un Database Hub con agenti IA: Cosa conta davvero dalla SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft ha appena inaugurato SQLCon 2026 insieme a FabCon ad Atlanta, e c’è un sacco di roba da analizzare. L’annuncio originale copre tutto, dai piani di risparmio alle funzionalità di conformità enterprise. Io salterò le slide sui prezzi enterprise e mi concentrerò sugli elementi che contano se sei uno sviluppatore che costruisce cose con Azure SQL e IA.

SQL MCP Server è in public preview

Questa è la notizia principale per me. Azure SQL Database Hyperscale ora ha un SQL MCP Server in public preview che ti permette di connettere in modo sicuro i tuoi dati SQL ad agenti IA e Copilot usando il Model Context Protocol.

Se hai seguito l’onda MCP — e onestamente, è difficile non notarla in questo momento — questa è una grande novità. Invece di costruire pipeline di dati personalizzate per alimentare i tuoi agenti IA con il contesto dal tuo database, ottieni un protocollo standardizzato per esporre i dati SQL direttamente. I tuoi agenti possono interrogare, ragionare e agire su informazioni del database in tempo reale.

Per quelli di noi che costruiscono agenti IA con Semantic Kernel o il Microsoft Agent Framework, questo apre un percorso di integrazione pulito. Il tuo agente deve controllare l’inventario? Cercare un record cliente? Validare un ordine? MCP gli dà un modo strutturato per farlo senza che tu debba scrivere codice di recupero dati su misura per ogni scenario.

GitHub Copilot in SSMS 22 è ora GA

Se passi del tempo in SQL Server Management Studio — e siamo onesti, la maggior parte di noi lo fa ancora — GitHub Copilot è ora disponibile in versione generale in SSMS 22. La stessa esperienza Copilot che già usi in VS Code e Visual Studio, ma per T-SQL.

Il valore pratico è semplice: assistenza via chat per scrivere query, refactoring di stored procedure, risoluzione di problemi di performance e gestione di task amministrativi. Niente di rivoluzionario come concetto, ma averlo direttamente in SSMS significa che non devi cambiare contesto verso un altro editor solo per ottenere aiuto IA sul tuo lavoro coi database.

Gli indici vettoriali hanno avuto un serio upgrade

Azure SQL Database ora ha indici vettoriali più veloci e più capaci con supporto completo per insert, update e delete. Questo significa che i tuoi dati vettoriali restano aggiornati in tempo reale — niente reindicizzazione batch necessaria.

Ecco le novità:

Quantizzazione per dimensioni degli indici più piccole senza perdere troppa accuratezza
Filtro iterativo per risultati più precisi
Integrazione più stretta con il query optimizer per performance prevedibili

Se stai facendo Retrieval-Augmented Generation (RAG) con Azure SQL come vector store, questi miglioramenti sono direttamente utili. Puoi tenere i tuoi vettori insieme ai dati relazionali nello stesso database, il che semplifica notevolmente la tua architettura rispetto a gestire un database vettoriale separato.

Gli stessi miglioramenti vettoriali sono disponibili anche in SQL Database in Fabric, dato che entrambi girano sullo stesso motore SQL sotto il cofano.

Database Hub in Fabric: gestione agentica

Questo punto è più orientato al futuro, ma è interessante. Microsoft ha annunciato il Database Hub in Microsoft Fabric (accesso anticipato), che ti dà un pannello unico su Azure SQL, Cosmos DB, PostgreSQL, MySQL e SQL Server via Arc.

L’aspetto interessante non è solo la vista unificata — è l’approccio agentico alla gestione. Agenti IA monitorano continuamente il tuo parco database, evidenziano cosa è cambiato, spiegano perché è importante e suggeriscono cosa fare dopo. È un modello human-in-the-loop dove l’agente fa il lavoro pesante e tu prendi le decisioni.

Per i team che gestiscono più di una manciata di database, questo potrebbe davvero ridurre il rumore operativo. Invece di saltare tra portali e controllare manualmente le metriche, l’agente porta il segnale a te.

Cosa significa questo per gli sviluppatori .NET

Il filo conduttore di tutti questi annunci è chiaro: Microsoft sta integrando agenti IA in ogni livello dello stack database. Non come un espediente, ma come un livello pratico di strumenti.

Se stai costruendo app .NET supportate da Azure SQL, ecco cosa farei concretamente:

Prova il SQL MCP Server se stai costruendo agenti IA. È il modo più pulito per dare ai tuoi agenti accesso al database senza plumbing personalizzato.
Attiva Copilot in SSMS se non l’hai già fatto — un guadagno di produttività gratuito per il lavoro SQL quotidiano.
Dai un’occhiata agli indici vettoriali se stai facendo RAG e attualmente usi un vector store separato. Consolidare su Azure SQL significa un servizio in meno da gestire.

Per concludere

L’annuncio completo contiene di più — piani di risparmio, assistenti per la migrazione, funzionalità di conformità — ma la storia per gli sviluppatori è nel MCP Server, nei miglioramenti vettoriali e nel livello di gestione agentica. Questi sono gli elementi che cambiano come costruisci, non solo come fai il budget.

Dai un’occhiata all’annuncio completo di Shireesh Thota per il quadro completo, e iscriviti per l’accesso anticipato al Database Hub se vuoi provare la nuova esperienza di gestione.

Azure DevOps MCP Server arriva in Microsoft Foundry: cosa significa per i tuoi agenti IA

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

MCP (Model Context Protocol) sta avendo il suo momento. Se hai seguito l’ecosistema degli agenti IA, probabilmente hai notato che i server MCP stanno spuntando ovunque — dando agli agenti la capacità di interagire con strumenti e servizi esterni attraverso un protocollo standardizzato.

Ora l’Azure DevOps MCP Server è disponibile in Microsoft Foundry, e questa è una di quelle integrazioni che ti fa pensare alle possibilità pratiche.

Cosa sta succedendo realmente qui

Microsoft ha già rilasciato l’Azure DevOps MCP Server come public preview — quello è il server MCP stesso. La novità è l’integrazione con Foundry. Ora puoi aggiungere l’Azure DevOps MCP Server ai tuoi agenti Foundry direttamente dal catalogo degli strumenti.

Per chi non conosce ancora Foundry: è la piattaforma unificata di Microsoft per costruire e gestire applicazioni e agenti alimentati dall’IA su larga scala. Accesso ai modelli, orchestrazione, valutazione, deployment — tutto in un unico posto.

La configurazione

La configurazione è sorprendentemente semplice:

Nel tuo agente Foundry, vai su Add Tools > Catalog
Cerca “Azure DevOps”
Seleziona l’Azure DevOps MCP Server (preview) e clicca su Create
Inserisci il nome della tua organizzazione e connetti

Tutto qui. Il tuo agente ora ha accesso agli strumenti Azure DevOps.

Controllare a cosa può accedere il tuo agente

Questa è la parte che apprezzo: non sei bloccato con un approccio tutto-o-niente. Puoi specificare quali strumenti sono disponibili per il tuo agente. Quindi se vuoi che legga solo i work item ma non tocchi le pipeline, puoi configurarlo. Principio del minimo privilegio, applicato ai tuoi agenti IA.

Questo conta per gli scenari enterprise dove non vuoi che un agente attivi accidentalmente una pipeline di deployment perché qualcuno gli ha chiesto di “aiutare con il release.”

Perché è interessante per i team .NET

Pensa a cosa abilita nella pratica:

Assistenti per la pianificazione degli sprint — agenti che possono recuperare work item, analizzare dati di velocità e suggerire la capacità dello sprint
Bot di code review — agenti che capiscono il contesto della tua PR perché possono effettivamente leggere i tuoi repo e work item collegati
Risposta agli incidenti — agenti che possono creare work item, interrogare i deployment recenti e correlare bug con modifiche recenti
Onboarding degli sviluppatori — “Su cosa dovrei lavorare?” ottiene una risposta reale basata su dati reali del progetto

Per i team .NET che già usano Azure DevOps per le loro pipeline CI/CD e la gestione dei progetti, avere un agente IA che può interagire direttamente con questi sistemi è un passo significativo verso un’automazione utile.

Il quadro più ampio di MCP

Questo fa parte di una tendenza più ampia: i server MCP stanno diventando il modo standard in cui gli agenti IA interagiscono con il mondo esterno. Li vediamo per GitHub, Azure DevOps, database, API SaaS — e Foundry sta diventando l’hub dove tutte queste connessioni convergono.

Se stai costruendo agenti nell’ecosistema .NET, vale la pena tenere d’occhio MCP. Il protocollo è standardizzato, gli strumenti stanno maturando, e l’integrazione Foundry lo rende accessibile senza dover configurare manualmente le connessioni server.

Per concludere

L’Azure DevOps MCP Server in Foundry è in preview, quindi aspettati che si evolva. Ma il workflow principale è solido: connettere, configurare l’accesso agli strumenti e lasciare che i tuoi agenti lavorino con i tuoi dati DevOps. Se sei già nell’ecosistema Foundry, è a pochi clic. Provalo e vedi quali workflow puoi costruire.

Consulta l’annuncio completo per la configurazione passo per passo e maggiori dettagli.

Dal laptop alla produzione: deploy di agenti IA su Microsoft Foundry con due comandi

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

Conosci quel divario tra “funziona sulla mia macchina” e “è in produzione e serve traffico”? Per gli agenti IA, quel divario è stato dolorosamente ampio. Devi provisionare risorse, fare il deploy dei modelli, configurare l’identità, impostare il monitoraggio — e questo è prima che qualcuno possa effettivamente chiamare il tuo agente.

L’Azure Developer CLI ha appena reso tutto questo una questione di due comandi.

Il nuovo workflow `azd ai agent`

Lascia che ti mostri come funziona nella pratica. Hai un progetto di agente IA — diciamo un agente concierge d’hotel. Funziona in locale. Vuoi farlo girare su Microsoft Foundry.

azd ai agent init
azd up

Tutto qui. Due comandi. azd ai agent init genera l’infrastructure-as-code nel tuo repo, e azd up provisiona tutto su Azure e pubblica il tuo agente. Ottieni un link diretto al tuo agente nel portale Foundry.

Cosa succede sotto il cofano

Il comando init genera template Bicep reali e ispezionabili nel tuo repo:

Una Foundry Resource (contenitore di livello superiore)
Un Foundry Project (dove vive il tuo agente)
Configurazione del deployment del modello (GPT-4o, ecc.)
Managed Identity con assegnazioni di ruoli RBAC appropriate
azure.yaml per la mappa dei servizi
agent.yaml con metadati dell’agente e variabili d’ambiente

Il punto chiave: tutto questo è tuo. È Bicep versionato nel tuo repo. Puoi ispezionarlo, personalizzarlo e committarlo insieme al codice del tuo agente. Nessuna scatola nera magica.

Il ciclo interno di sviluppo

Quello che mi piace davvero è l’esperienza di sviluppo locale. Quando stai iterando sulla logica dell’agente, non vuoi fare il redeploy ogni volta che cambi un prompt:

azd ai agent run

Questo avvia il tuo agente in locale. Combinalo con azd ai agent invoke per inviare prompt di test, e hai un ciclo di feedback stretto. Modificare codice, riavviare, invocare, ripetere.

Il comando invoke è anche intelligente nel routing — quando un agente locale è in esecuzione, lo punta automaticamente. Quando non lo è, va all’endpoint remoto.

Monitoraggio in tempo reale

Questa è la funzionalità che mi ha convinto. Una volta che il tuo agente è in deploy:

azd ai agent monitor --follow

Ogni richiesta e risposta che passa attraverso il tuo agente viene trasmessa al tuo terminale in tempo reale. Per il debug di problemi in produzione, non ha prezzo. Niente ricerche in Log Analytics, niente attese per l’aggregazione delle metriche — vedi cosa sta succedendo adesso.

Il set completo dei comandi

Ecco il riferimento rapido:

Comando	Cosa fa
`azd ai agent init`	Scaffold di un progetto agente Foundry con IaC
`azd up`	Provisiona risorse Azure e fa il deploy dell’agente
`azd ai agent invoke`	Invia prompt all’agente remoto o locale
`azd ai agent run`	Esegue l’agente in locale per lo sviluppo
`azd ai agent monitor`	Streama log in tempo reale dall’agente pubblicato
`azd ai agent show`	Controlla salute e stato dell’agente
`azd down`	Pulisce tutte le risorse Azure

Perché è importante per gli sviluppatori .NET

Anche se l’esempio nell’annuncio è basato su Python, la storia dell’infrastruttura è language-agnostic. Il tuo agente .NET ottiene lo stesso scaffolding Bicep, lo stesso setup di managed identity, la stessa pipeline di monitoraggio. E se stai già usando azd per le tue app .NET Aspire o deployment Azure, si integra direttamente nel tuo workflow esistente.

Il divario di deployment per gli agenti IA è stato uno dei maggiori punti di attrito nell’ecosistema. Passare da un prototipo funzionante a un endpoint di produzione con identità, networking e monitoraggio appropriati non dovrebbe richiedere una settimana di lavoro DevOps. Ora richiede due comandi e qualche minuto.

Per concludere

azd ai agent è disponibile ora. Se hai rimandato il deployment dei tuoi agenti IA perché il setup dell’infrastruttura sembrava troppo lavoro, provalo. Consulta il walkthrough completo per la guida passo per passo inclusa l’integrazione di un’app chat frontend.

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.

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

Scrivi per The .NET Blog

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog una pubblicazione guidata dalla community dove gli sviluppatori condividono approfondimenti, tutorial e storie su .NET, Azure, AI e sviluppo cloud-native. Accogliamo contributi da sviluppatori di tutti i che tu stia scrivendo il tuo primo articolo tecnico o sia un relatore esperto.livelli

Come Partecipare

Tutto vive su GitHub e segue un flusso di lavoro basato su pull request. Ecco come iniziare:

1. Fai il Fork del Repository

Vai su github.com/thedotnetblog/blog e crea un fork nel tuo account GitHub.

2. Crea il tuo Profilo Autore

Se il tuo primo contributo, aggiungiti come autore creando una cartella in content/authors/tuo-username/ con un file index.md:

---
title: "Il tuo Nome"
id: "tuo-username"
role: "Il tuo ruolo o titolo"
bio: "Una breve biografia su di te."
avatar: "/img/authors/tuo-avatar.jpg"
socials:
 - platform: "GitHub"
 url: "https://github.com/tuo-username"
 - platform: "Twitter"
 url: "https://x.com/tuo-username"
---

Aggiungi la tua immagine avatar (quadrata, almeno 200200px) in static/img/authors/.

3. Scrivi il tuo Articolo

Crea una nuova cartella in content/posts/tuo-username/slug-del-tuo-articolo/ e aggiungi un file index.md:

---
title: "Titolo del tuo Articolo"
date: 2025-01-01
author: "tuo-username"
description: "Una breve descrizione del tuo articolo."
tags: ["dotnet", "azure"]
---

Il contenuto del tuo articolo in Markdown...

4. Apri una Pull Request

Invia le tue modifiche al tuo fork e apri una pull request verso il branch main. Il nostro team la esaminer e fornir feedback entro pochi giorni.

Cosa Cerchiamo

** guide passo passo su .NET, Azure, AI, Blazor, Aspire e altroTutorial**
** esplorazioni dettagliate di una tecnologia, pattern o architetturaApprofondimenti**
Storie della la tua esperienza con .NET in produzionecommunity
Resoconti di riassunti di conferenze, meetup o webinareventi

Linee Guida

Il contenuto deve essere tecnico e pertinente all’ecosistema .NET
Gli esempi di codice devono essere accurati e testati in un progetto reale
Includi una descrizione significativa e almeno un tag pertinente
Gli articoli vengono tradotti automaticamente in tutte le lingue supportate

Contatti

Apri una issue su GitHub o contattaci su X / Twitter. Saremmo felici di accoglierti nella community!

The .NET Blog

NDC Oslo 2026

In numeri

Speaker confermati

Biglietti

Altri eventi NDC nel 2026

Link

.NET Day Switzerland 2026

Cosa ti aspetta

Biglietti

Organizzatori

Link

SDD Conference 2026

Argomenti

Speaker

Biglietti e informazioni

Azure DevOps MCP Server Aggiornamento Aprile: Query WIQL, Auth PAT e MCP Apps Sperimentali

Supporto Query WIQL

Personal Access Tokens

Annotazioni MCP

Consolidamento degli Strumenti Wiki

Sperimentale: MCP Apps

.NET 10 Arriva con Ubuntu 26.04 LTS — Le Novità

Installa .NET 10 in due comandi

Container: aggiorna -noble a -resolute

Native AOT: avvio in 3ms, binario da 1,4MB

Hai bisogno di .NET 8 o 9?

Azure MCP Server Ora è un .mcpb — Installalo senza Nessun Runtime

Cos’è un MCP Bundle?

Come installarlo

Cosa puoi fare

Per iniziare

Azure SDK Aprile 2026: AI Foundry 2.0 e Cosa Devono Sapere gli Sviluppatori .NET

Azure.AI.Projects 2.0.0 — Breaking Change che Hanno Senso

Cosmos DB Java: Correzione Critica di Sicurezza (RCE)

Nuove Librerie di Provisioning per .NET

CodeAct in Agent Framework: Come Dimezzare la Latenza del tuo Agente

Cos’è CodeAct?

La componente di sicurezza: Micro-VM Hyperlight

Configurazione minima

Quando usare CodeAct (e quando no)

Provalo ora

Dove il tuo Agente Ricorda le Cose? Guida Pratica all'Archiviazione della Cronologia Chat

Due pattern fondamentali

Come Agent Framework astrae questo

Riferimento rapido ai provider

Come scegliere

GPT-5.5 È Arrivato su Azure Foundry — Cosa Devono Sapere i Sviluppatori .NET

La progressione di GPT-5

Cosa è cambiato davvero

Prezzi

Perché Foundry è importante

VS Code 1.118: Copilot CLI ottiene Nomi di Sessione, Badge di Modello e TypeScript 7.0 Nightly

Copilot CLI: le sessioni hanno nomi reali

Cambia sessione più velocemente

Badge modello nella chat

Selezione automatica del modello in Copilot CLI

Opt-in per TypeScript 7.0 Nightly

Aspire 13.2: Supporto Bun, Contenitori Migliori e Meno Attrito nel Debug

Bun è Ora di Prima Classe

Yarn Più Affidabile

Miglioramenti ai Container

Miglioramenti al Debug

68 Minuti al Giorno a Ri-Spiegare il Codice? C'è una Soluzione

La Bugia della Finestra di Contesto

La Tassa di Compattazione

auto-memory: Uno Strato di Richiamo, Non un Sistema di Memoria

Conclusione

Foundry Toolboxes: Un unico endpoint per tutti i tool degli agenti

Cos’è una Toolbox?

I quattro pilastri (due disponibili oggi)

Esempio pratico

Nessun lock-in con Foundry Agents

Perché è importante adesso

Conclusione

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

Gli hook, in breve

Come funziona il rilevamento

Dettagli per linguaggio

Python

Container: aggiorna `-noble` a `-resolute`