Visual Studio | The .NET Blog

Aggiornamento di aprile di Visual Studio 2026: agente cloud, agenti personalizzati e agente debugger

Emiliano Montesdeoca — Thu, 14 May 2026 00:00:00 +0000

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

L’aggiornamento di aprile di Visual Studio 2026 (18.5) include l’integrazione dell’agente cloud, agenti personalizzati a livello utente, strumenti C++ che raggiungono la GA e un nuovo Agente Debugger.

Agente cloud: delegare il lavoro a una sessione Copilot remota

Dal selettore di agenti nella finestra Chat, selezionando Cloud è possibile delegare un’attività a un agente di coding Copilot remoto. Si descrive il lavoro, l’agente crea un issue GitHub nel repository, poi apre una PR quando ha finito. Si riceve una notifica con “View PR” / “Open in browser” — tutto funziona mentre si continua a programmare, o anche con l’IDE chiuso.

Gli agenti personalizzati ora ti seguono ovunque

Gli agenti personalizzati a livello utente memorizzati in %USERPROFILE%/.github/agents/ non sono più limitati al repository — ti seguono attraverso i progetti. Il percorso di archiviazione è configurabile in Tools > Options > GitHub > Copilot > Chat. Il pulsante + nel selettore di agenti consente di creare nuovi agenti direttamente. Ottengono le stesse capacità degli agenti con scope di repository: consapevolezza dello spazio di lavoro, strumenti, selezione del modello e connessioni MCP.

Agenti integrati: Agent, Ask, Copilot CLI, Debugger, Modernize, Profiler.

Gli strumenti di editing del codice C++ diventano GA

Due strumenti — get_symbol_call_hierarchy e get_symbol_class_hierarchy — sono ora attivi per impostazione predefinita. Forniscono a Copilot una navigazione consapevole del linguaggio nelle basi di codice C++, coprendo gerarchie di ereditarietà e catene di chiamate di funzioni. Abilitare tramite l’icona Tools in Copilot Chat. Funziona meglio con i modelli di tool-calling.

Agente Debugger: correzioni validate contro il comportamento runtime reale

Inizia da un issue GitHub o Azure DevOps (o una descrizione in linguaggio naturale), passa alla modalità Debugger, e l’agente:

Crea un riproduttore minimo
Genera ipotesi di errore
Strumenta l’app con tracepoint e breakpoint condizionali
Esegue una vera sessione di debug
Analizza la telemetria in tempo reale
Suggerisce una correzione precisa

Si rimane nel ciclo durante tutto il processo — è interattivo, non completamente autonomo.

Correzione della priorità IntelliSense

VS ora sopprime i completamenti Copilot mentre la lista IntelliSense è attiva. Un solo suggerimento alla volta. Era un punto di attrito frequente e ora è attivo per impostazione predefinita.

Note di rilascio complete e download su devblogs.microsoft.com.

Supporto SDK-Style per i Progetti di Estensione in Visual Studio

Emiliano Montesdeoca — Wed, 13 May 2026 00:00:00 +0000

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

Il supporto SDK-style per i progetti di estensione basati su VSSDK è ora ufficiale in Visual Studio 18.5 — i progetti di estensione VSIX classici possono abbandonare il vecchio formato .csproj in stile MPF.

Cosa cambia nel file di progetto

Il cambiamento più visibile è quanto diventa più piccolo il file di progetto. Una tipica estensione VSSDK ora si presenta così:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net472</TargetFramework>
 <VSSDKBuildToolsAutoSetup>true</VSSDKBuildToolsAutoSetup>
 <VsixDeployOnDebug>true</VsixDeployOnDebug>
 <GeneratePkgDefFile>true</GeneratePkgDefFile>
 </PropertyGroup>
 <ItemGroup><ProjectCapability Include="CreateVsixContainer" /></ItemGroup>
 <ItemGroup>
 <PackageReference Include="Microsoft.VisualStudio.SDK" Version="17.14.40265" ExcludeAssets="runtime" />
 <PackageReference Include="Microsoft.VSSDK.BuildTools" Version="18.5.38461" />
 </ItemGroup>
</Project>

VSSDKBuildToolsAutoSetup=true applica valori predefiniti ragionevoli: CreateVsixContainer=true e il legacy DeployExtension=false. Questa singola proprietà sostituisce una parte significativa di ciò che in precedenza doveva essere specificato esplicitamente.

Miglioramenti dei tempi di build

Sono inclusi Fast Up-To-Date Check e supporto per la build incrementale. Per soluzioni grandi con piccole modifiche, questo si traduce in una riduzione del tempo di build fino al 75% — significativa se si sta iterando su un’estensione all’interno di una grande soluzione host.

Nuovi progetti vs. esistenti

I nuovi progetti di estensione creati in 18.5 utilizzano automaticamente lo stile SDK. Le estensioni in stile MPF esistenti continuano a funzionare — la migrazione è opzionale. Da tenere presente durante la migrazione: aggiungere <UseWpf>true</UseWpf> se l’estensione usa XAML. È inoltre necessario contrassegnare l’estensione come distribuibile nel file .sln o .slnx.

Il designer vsixmanifest viene sostituito dall’editor XML come predefinito — clic destro → Apri con se si desidera il vecchio designer.

Percorso di migrazione agentivo

L’agente Modernize in vs-agent-plugins può automatizzare la migrazione. Diverse estensioni reali sono già state convertite in questo modo: Smart Screen, Command Explorer, Postfix Templates e Whitespace Visualizer di Mads Kristensen.

Da notare

VisualStudio.Extensibility (il framework di estensibilità più recente) supportava già lo stile SDK. Questo aggiornamento porta la parità con il percorso VSSDK classico. L’unico requisito è il carico di lavoro per lo sviluppo di estensioni di Visual Studio.

Dettagli completi nel post ufficiale.

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

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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

Nota: Il sandboxing è disponibile su macOS e Linux per ora. Il supporto Windows è in arrivo — scenari remoti come WSL funzionano però.

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.