Developer Tools | The .NET Blog

VS Code 1.119: OpenTelemetry per le sessioni degli agenti, integrazione del browser e sicurezza

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

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

VS Code 1.119 è stato rilasciato il 6 maggio 2026 (con una patch di sicurezza 1.119.1 poco dopo). La versione si concentra sull’osservabilità degli agenti, l’interazione con il browser e la riduzione delle interruzioni.

Tracciamento OpenTelemetry per le sessioni degli agenti

Questa è la funzionalità di punta per chiunque esegua agenti in produzione o esegua il debug di flussi di lavoro agentici. Abilitarla con due impostazioni:

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

Le tracce seguono le convenzioni semantiche GenAI. Ogni richiesta dell’agente produce uno span root invoke_agent con span figli annidati: chat, execute_tool e execute_hook. L’utilizzo dei token viene riportato per richiesta — inclusi i conteggi di lettura della cache e creazione della cache.

Funziona con l’agente locale, l’agente in background Copilot CLI e l’agente Claude. Qualsiasi backend compatibile OTLP accetta le tracce — l’Aspire Dashboard standalone funziona bene per lo sviluppo locale.

Gli agenti ora possono accedere alle schede del browser

Gli agenti possono richiedere l’accesso alle schede del browser integrato — ma non è automatico. È necessario condividere esplicitamente una scheda tramite il selettore di contesto, trascinamento e rilascio o contesto suggerito. C’è un pulsante di condivisione nel browser per revocare l’accesso. Quando un agente tenta di aprire una nuova scheda sullo stesso dominio di una scheda già aperta (non condivisa), VS Code chiede di riutilizzare la scheda esistente.

Utilizzo ottimizzato dei token

Un modello leggero sperimentale ora gestisce le liste di attività degli agenti, mantenendo questo lavoro amministrativo lontano dal modello primario più costoso. Riduce il consumo di token per attività che non richiedono piena capacità di ragionamento.

Fiducia e sicurezza

Meno interruzioni: VS Code 1.119 riduce i prompt per le richieste di accesso alla rete e le scritture nelle cartelle temporanee da parte degli agenti. La patch 1.119.1 risolve specifici problemi di sicurezza — vale la pena aggiornare se non è ancora stato fatto.

Cambio rapido all’anteprima Markdown

Piccolo ma utile: ora è possibile passare rapidamente dall’editor corrente all’anteprima Markdown senza navigare.

VS Code Agents (anteprima Insiders)

L’interfaccia di sessione degli agenti riprogettata — nuovo selettore di repository (locale/repos/remoto), miglioramenti delle sotto-sessioni, rifinitura web e mobile, animazioni di avanzamento — è disponibile in Insiders su insiders.vscode.dev/agents.

Changelog completo: code.visualstudio.com/updates/v1_119.

Azure Data Studio è stato ritirato: sposta il tuo flusso di Azure SQL su VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

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

Azure Data Studio è stato ritirato il 6 febbraio 2025, con supporto fino al 28 febbraio 2026 — il sostituto consigliato è VS Code con l’estensione MSSQL.

Cosa installare

Tre elementi per iniziare:

Estensione MSSQL — cerca “SQL Server (mssql)” nel Marketplace di VS Code
Estensione SQL Database Projects — schema come codice, validazione della build, pubblicazione guidata
.NET 8 SDK — richiesto dal sistema di build; l’SDK mancante è il problema più comune al primo avvio

Migrare le connessioni e le impostazioni di ADS

L’estensione MSSQL include l’ADS Migration Toolkit, che gestisce la migrazione una tantum in un flusso guidato: connessioni salvate, gruppi di connessioni, impostazioni e tasti di scelta rapida vengono importati automaticamente.

Ripristinare la memoria muscolare del F5

Gli utenti di ADS si affidano a F5 per eseguire le query. Installa l’estensione MSSQL Database Management Keymap per recuperare i tasti di scelta rapida in stile ADS, incluso F5.

SQL Database Projects: schema come codice

Clic destro su un progetto → Pubblica → configura la destinazione → rivedi lo script T-SQL generato → distribuisci. L’anteprima dello script prima del deployment è la funzionalità di sicurezza chiave. I modelli di elementi generano stub per tabelle, stored procedure e viste — lo stesso flusso di SSDT.

Problema frequente: un’incompatibilità della piattaforma di destinazione nel file .sqlproj causerà errori di build se il progetto è stato creato per una versione diversa di SQL Server.

Schema Compare e Schema Designer

L’estensione include anche Schema Compare (differenza tra il progetto e il database distribuito) e Schema Designer (modifica visuale dello schema senza scrivere DDL a mano).

Sviluppatori di Microsoft Fabric

La configurazione è identica, ma inizia dal portale Fabric e connetti prima il database a Git prima di aprirlo in VS Code. Microsoft ha una guida dedicata: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

In conclusione

La migrazione è un flusso guidato una tantum, non una ricostruzione manuale. Installa i tre strumenti, esegui l’ADS Migration Toolkit, ripristina i tuoi tasti di scelta rapida e sarai di nuovo operativo in meno di 10 minuti.

Consulta l’articolo completo per screenshot passo-passo e la guida specifica per Fabric.

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.

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.

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.

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.

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 è.

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.

.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.

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.

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.

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.

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.

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.

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.