Msvc.Info

VS MCP Server — Panoramica del Progetto & Stime di Sviluppo

Cos'è

Un'estensione per Visual Studio 2022 che esegue un server MCP (Model Context Protocol) all'interno di Visual Studio, dando agli assistenti AI di coding accesso in tempo reale alla comprensione semantica di Roslyn del codice sorgente — lo stesso motore che alimenta IntelliSense.

Invece di fare grep alla cieca sui file, gli strumenti AI ottengono accesso strutturato e semantico alla struttura della soluzione, ricerca simboli, alberi di ereditarietà, refactoring, esecuzione build/test e contesto dell'editor — tutto attraverso un protocollo standardizzato con risparmio del 70–90% sui token grazie a formati di output compatti.

Architettura

graph TB
    subgraph VS["Visual Studio 2022"]
        EXT["Extension Entry\nPacchetto VSIX"]
        HOST["MCP Server Host\navvia · ferma · riavvia"]
        SDK["MCP SDK Server\nModelContextProtocol"]
        SETTINGS["Interfaccia Impostazioni\nToolWindow + XAML"]
        STORE[("Impostazioni JSON\nper-soluzione .mcp/")]

        EXT --> HOST
        EXT --> SETTINGS
        HOST --> SDK
        SETTINGS --> STORE
    end

    subgraph TOOLS["20 Tool MCP"]
        NAV["Navigazione\nSolutionTree · Outline\nProjectRefs"]
        SYM["Ricerca Simboli\nFind · Definition · Usages\nInheritance · Callers"]
        EDIT["Contesto Editor\nActiveFile · Selection"]
        CMD["Comandi\nBuild · Clean · AsyncTests"]
        PATH["Traduzione Percorsi\nWindows · WSL · URI"]
        REF["Refactoring\nRename · Format"]
    end

    SDK --> TOOLS
    TOOLS -.->|"Roslyn API"| ROSLYN[("Roslyn\nWorkspace")]
    TOOLS -.->|"DTE API"| DTE[("VS DTE\nServizi")]

    subgraph TRANSPORT["Trasporti"]
        HTTP["HTTP\nHttpListener\nporta 3001"]
        SSE["SSE\nServer-Sent Events"]
        STDIO["Stdio Bridge\n.NET 8 Console"]
    end

    HOST --> HTTP
    HOST --> SSE
    STDIO -->|"HTTP"| HTTP

    CC["AI Coding CLI"] -->|"HTTP"| HTTP
    GEM["Gemini CLI / Codex"] -->|"HTTP"| HTTP
    CD["AI Desktop App"] -->|"stdio"| STDIO
    OTHER["Aider · Cline\nWindsurf · OpenCode"] -->|"HTTP/SSE"| HTTP
  

Struttura della Soluzione

Stima dei Tempi di Sviluppo

Quanto impiegherebbe un super senior developer .NET a costruire tutto da zero, scrivendo tutto il codice a mano?

Dettaglio per Fase

Dove Va Realmente il Tempo

Fattori di Rischio

Cosa Cambia con l'Assistenza AI

Osservazioni Chiave

1. La ricerca è il costo nascosto più grande. Il nuovo modello di estensibilità VS è scarsamente documentato. Il protocollo MCP ha casi limite. La superficie API di Roslyn è enorme. Un super senior naviga più veloce, ma deve comunque leggere e sperimentare. Il lookup AI (ChatGPT) fa risparmiare ~1–2 giorni rispetto alla lettura pura della documentazione.
2. Ricerca Simboli (Roslyn) è la fase implementativa più difficile. 7 tool che colpiscono API Roslyn diverse (SymbolFinder, syntax tree, modello semantico). Gerarchia delle chiamate ed ereditarietà richiedono comprensione profonda del modello di compilazione di Roslyn. 3 giorni è ottimistico — potrebbe facilmente diventare 5 con i casi limite.
3. Il trasporto custom è un costo inaspettato. L'SDK MCP ufficiale non include un trasporto HTTP per .NET 4.7.2. Costruire un trasporto basato su HttpListener con gestione corretta del ciclo di vita (riavvio, riuso porta, dispose) è un lavoro da 2 giorni pieni che non sarebbe ovvio dalla lettura iniziale delle specifiche.
4. Il debug in VS è intrinsecamente lento. Ogni ciclo di test richiede l'avvio di un'istanza sperimentale VS (~30s di startup). Questo moltiplica i tempi di debug per ~3x rispetto allo sviluppo .NET normale. Nessuna quantità di esperienza elimina questo overhead.
5. La UI delle impostazioni ha una complessità sproporzionata. RemoteUserControl (XAML dell'estensibilità VS) non ha converter standard, supporto DataTemplate limitato, e il XAML deve essere EmbeddedResource con PageRemove. Un semplice dialogo impostazioni richiede 2 giorni invece degli 0.5 previsti.

Timeline di Sviluppo Reale (con AI Coding Assistant)

Il progetto è stato costruito con un AI coding assistant che ha scritto ~90% del codice, diretto da un senior developer che ha progettato l'architettura e preso tutte le decisioni. Ruolo umano: architettura, visione, decisioni, prompting, review, testing manuale in VS. Lo sviluppo è avvenuto in burst sporadici nell'arco di 9 mesi, non lavoro continuativo a tempo pieno.

Sprint di Sviluppo

Stima vs Realtà

Osservazioni Chiave

1. Lo sviluppo sporadico funziona sorprendentemente bene con l'AI. 9 mesi trascorsi, ma solo ~10 giorni pieni di lavoro effettivo. Il sistema memory bank dell'AI assistant ha significato zero tempo di ramp-up tra le sessioni — anche dopo pause di 3 mesi, il contesto veniva ripristinato istantaneamente.
2. La UI delle impostazioni è stata l'unica area senza speedup (1x). Il RemoteUserControl dell'estensibilità VS non ha converter standard, ha quirk XAML non documentati, e richiede workaround con EmbeddedResource + PageRemove. L'AI non poteva abbreviare il dolore perché la documentazione praticamente non esiste.
3. Il 21 Gennaio è stata la giornata monstre: 21 commit. Espansione impostazioni, filtraggio tool, RenameSymbol, FormatDocument e pubblicazione VS Marketplace — tutto in un solo giorno. Questo tipo di produttività è possibile solo quando l'AI gestisce il boilerplate mentre l'umano si concentra sulle decisioni architetturali.
4. Il vero collo di bottiglia è il testing manuale in VS. Ogni modifica richiede l'avvio di un'istanza sperimentale VS (~30s), la connessione di un client MCP, e il test manuale delle risposte dei tool. I test unitari coprono la logica, ma il testing di integrazione è intrinsecamente lento. Ecco perché lo speedup è 2.1x invece del 5–6x visto in altri progetti.
5. Il marketing ha richiesto quanto alcune feature. 2 giorni per i materiali marketing (articolo Dev.to, LinkedIn, landing page, Twitter) è paragonabile alla costruzione dell'intero sistema impostazioni. Il lavoro non-codice non beneficia altrettanto dell'assistenza AI al coding.