GitHub Copilot | The .NET Blog

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

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

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

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

Supporto Query WIQL

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

Personal Access Tokens

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

Annotazioni MCP

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

Consolidamento degli Strumenti Wiki

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

Sperimentale: MCP Apps

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

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

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.

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

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

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

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

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

La Bugia della Finestra di Contesto

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

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

La Tassa di Compattazione

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

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

pip install auto-memory

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

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

Conclusione

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

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

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

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

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

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

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

Configurazione con Copilot durante azd init

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

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

Prerequisiti:

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

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

Cosa fa davvero

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

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

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

Risoluzione degli errori con Copilot

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

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

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

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

Configurare il comportamento predefinito

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

azd config set copilot.errorHandling.category troubleshoot

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

azd config set copilot.errorHandling.fix allow

Ritorno alla modalità interattiva in qualsiasi momento:

azd config unset copilot.errorHandling.category

Conclusione

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

Leggi l’annuncio originale qui.

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

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

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

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

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.

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

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

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

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

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

Cosa fa Git-APE concretamente

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

Ecco il setup:

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

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

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

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

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

Perché è importante

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

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

La pulizia è altrettanto semplice:

@git-ape destroy my-resource-group

La mia opinione

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

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

Per concludere

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

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

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

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

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

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

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

Non è solo un motore di suggerimenti di codice

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

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

Due modi per iniziare

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

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

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

La suddivisione degli issue è azionabile

Ogni issue viene con un livello di criticità:

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

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

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

I percorsi di upgrade coperti

Per .NET specificamente:

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

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

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

La mia opinione

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

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

Conclusione

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

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

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.