Aspire | The .NET Blog

Endpoint Privati, VNet, NSG — Aspire Gestisce la Rete Ora

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

Ho visto questo scenario troppe volte. L’app è pronta. La demo è fantastica. Poi arriva la checklist di sicurezza: porta lo storage fuori da internet pubblico, esegui all’interno di un VNet, fornisci IP in uscita per l’allowlist del partner, dimostra che solo le subnet giuste parlano con i servizi giusti.

A quel punto il modello dell’applicazione e il modello dell’infrastruttura iniziano a divergere in modi che sono dolorosi da mantenere.

Il nuovo supporto per le reti aziendali Azure di Aspire affronta questo direttamente. Descrivi la forma della rete accanto alle risorse che la usano, nel tuo AppHost.

I Blocchi di Costruzione

Ecco a cosa serve ogni concetto di rete Azure, sintetizzato:

Funzionalità	Usala quando	Perché è importante
Rete virtuale	Hai bisogno di uno spazio di indirizzi privato	Il confine di rete per subnet, endpoint privati e routing
Subnet	Devi separare i carichi di lavoro all’interno del VNet	Ogni parte del sistema ottiene il proprio intervallo di indirizzi e superficie di policy
Subnet delegata	Un servizio di piattaforma (come ACA) deve gestire una subnet	Consente al servizio di posizionare infrastruttura gestita nel tuo VNet in modo sicuro
Gateway NAT	Hai bisogno di IP pubblici in uscita prevedibili	Indirizzo stabile per allowlist e auditing
Endpoint privato	Vuoi una risorsa PaaS raggiungibile privatamente	Inserisce un IP privato per quel servizio nel tuo VNet, rimuove l’esposizione pubblica
NSG	Hai bisogno di regole di traffico a livello di subnet	Permetti/nega esplicito per il traffico in entrata e in uscita per subnet

Descrivendolo nel tuo AppHost

Il cambiamento chiave qui è che stai modellando la rete insieme alle risorse che la usano, non in un file Bicep separato che si allontana dal modello dell’applicazione nel tempo.

Dall’AppHost puoi:

Creare VNet e subnet con AddVirtualNetwork() e AddSubnet()
Allegare un gateway NAT alle subnet per IP in uscita stabili
Creare endpoint privati per storage, Key Vault, SQL e altri servizi PaaS
Definire NSG con regole di sicurezza in entrata e in uscita
Configurare Perimetri di Sicurezza di Rete per policy tra risorse

Il risultato è che quando esegui azd up, l’infrastruttura corrisponde a ciò che il modello dell’applicazione dice di cui ha bisogno. Non quello che dice un template mantenuto manualmente.

Perché Questo è Importante per le Applicazioni Reali

Alcune cose che diventano significativamente più facili una volta che la rete è modellata in Aspire:

Endpoint privati per Key Vault e storage — descrivi WithPrivateEndpoint() su quelle risorse, e Aspire gestisce la configurazione delle zone DNS e l’allegato degli endpoint. L’app non cambia mai.

IP in uscita coerenti — aggiungi un gateway NAT alla subnet pertinente e ogni richiesta in uscita dalla tua app passa attraverso un IP noto e stabile. I partner possono aggiungerlo all’allowlist. I revisori possono tracciarlo.

Regole NSG dal codice — invece di cliccare nel portale o mantenere un frammento Bicep, le tue regole di sicurezza vivono nell’AppHost accanto alle risorse che proteggono.

Questo è il tipo di integrazione che non rende le demo eccitanti ma rende i sistemi di produzione manutenibili.

Conclusione

La sicurezza di rete che appare tardi nel ciclo di vita del progetto è un problema risolto se la modelli insieme all’app fin dall’inizio. Il supporto per le reti aziendali di Aspire rende ciò possibile senza richiedere una traccia di infrastruttura separata.

Dettagli completi nel post originale: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Supporto Kubernetes, Log del Browser e la Skill Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Cinque settimane non sono molto per un rilascio, ma Aspire 13.3 non sembra tale. Gli elementi principali sono significativi: deployment di Kubernetes e AKS di prima classe con Helm, una skill di onboarding assistita da agente chiamata Aspireify, cattura dei log del browser direttamente nel dashboard e risultati dei comandi strutturati. In più, 45 nuove funzionalità, 134 miglioramenti e 93 correzioni di bug.

Passiamo ai punti salienti.

Aspireify: Onboarding Assistito da Agente

Aggiungere Aspire a un progetto esistente sembra semplice — inserisci un AppHost, fatto. In pratica comporta molta archeologia: quali porte contano, quali variabili d’ambiente sono dipendenze reali, quali servizi Docker Compose devono corrispondere alle integrazioni Aspire.

La nuova skill Aspireify fornisce al tuo agente di codice un flusso di lavoro guidato esattamente per questo. Quando aspire init crea un AppHost scheletro, la skill Aspireify aiuta l’agente a ispezionare il repository, capire come funziona già e collegare l’AppHost per adattarsi all’app — non il contrario.

La postura predefinita è “minimizzare le modifiche al tuo codice.” Se la tua app legge già DATABASE_URL, l’agente lo mappa con WithEnvironment() invece di chiederti di riscrivere la tua configurazione. Se una porta è codificata in modo fisso, la skill indica all’agente quando preservarla.

Questo è il tipo di tooling IA che fa davvero risparmiare tempo invece di generare più lavoro da revisionare.

Deployment di Kubernetes e AKS di Prima Classe

Questo era nella lista dei desideri da un po’. Aspire 13.3 include il supporto di deployment di Kubernetes e AKS di prima classe con Helm. Ora puoi puntare ad AKS come destinazione di deployment direttamente dagli strumenti Aspire.

Per i team che già eseguono carichi di lavoro di produzione su AKS, questo colma una lacuna significativa. Il tuo modello di applicazione Aspire ora ha un percorso pulito dallo sviluppo locale a Kubernetes senza la necessità di scrivere manualmente chart Helm.

Log del Browser nel Dashboard

Questa è una di quelle funzionalità che sembrano piccole finché non stai facendo debug di un problema frontend.

La nuova API WithBrowserLogs() collega una risorsa browser tracciata a qualsiasi risorsa capace di endpoint. Aspire lancia Chromium usando un pipe CDP privato e trasmette log della console, richieste di rete ed errori direttamente nel flusso di log della risorsa:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

L’AppHost TypeScript supporta lo stesso:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Errori della console, richieste di rete fallite, eccezioni lato client — tutto visibile nello stesso dashboard dove stai già guardando trace e metriche. Nessun cambio di tab verso le DevTools del browser per le cose di base.

Risultati dei Comandi Strutturati

I comandi delle risorse hanno ricevuto un aggiornamento significativo. Fino ad ora, i comandi restituivano successo/fallimento. Ora restituiscono risultati strutturati: testo, JSON o markdown che fluisce attraverso il modello, l’interfaccia del dashboard, la CLI e gli strumenti MCP.

Il dashboard lega tutto questo con un nuovo centro notifiche nell’intestazione. I risultati dei comandi appaiono come notifiche con timestamp con rendering markdown e un’azione “Visualizza risposta”.

Questo rende i comandi delle risorse veramente componibili. Un’integrazione ora può esporre un comando che restituisce un output significativo — come un URL di tunnel — invece di cambiare semplicemente lo stato da qualche parte.

Conclusione

Aspire 13.3 vale l’aggiornamento anche solo per il supporto Kubernetes. I log del browser e i risultati dei comandi strutturati sembrano il tipo di miglioramenti della qualità della vita che si accumulano rapidamente in un flusso di lavoro di sviluppo quotidiano.

Note di rilascio complete: What’s New in Aspire 13.3

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

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

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

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

Bun è Ora di Prima Classe

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

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

Yarn Più Affidabile

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

Miglioramenti ai Container

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

Miglioramenti al Debug

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

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

Global Azure Spain 2026

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

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

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

Punti salienti dell’agenda

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

Biglietti

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

Azure Tour 2026

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

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

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

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.

.NET Aspire 13.2 Vuole Essere il Migliore Amico del Tuo Agente IA

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

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

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

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

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.

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

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

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.

La Dashboard di Aspire 13.2 ora ha un'API di telemetria — e cambia tutto

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

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

Se hai sviluppato applicazioni distribuite con .NET Aspire, sai già che la dashboard è la cosa migliore dell’intera esperienza. Tutti i tuoi trace, log e metriche in un unico posto — niente Jaeger esterno, niente configurazione di Seq, niente momenti “fammi controllare l’altro terminale”.

Aspire 13.2 ha appena migliorato tutto significativamente. James Newton-King ha annunciato l’aggiornamento, e onestamente? Le funzionalità di esportazione telemetria e l’API da sole giustificano l’upgrade.

Esportare telemetria come una persona normale

Ecco lo scenario che abbiamo vissuto tutti: stai debuggando un problema distribuito, finalmente lo riproduci dopo venti minuti di setup, e ora devi condividere con il team quello che è successo. Prima? Screenshot. Copia e incolla degli ID delle trace. Il solito caos.

Aspire 13.2 aggiunge un dialog Gestisci log e telemetria dove puoi:

Pulire tutta la telemetria (utile prima di un tentativo di riproduzione)
Esportare telemetria selezionata in un file ZIP nel formato standard OTLP/JSON
Re-importare quel ZIP in qualsiasi dashboard Aspire successivamente

Quest’ultimo punto è la funzionalità killer. Riproduci un bug, esporti la telemetria, la alleghi al tuo work item, e il tuo collega può importarla nella propria dashboard per vedere esattamente quello che hai visto tu. Niente più “riesci a riprodurlo sulla tua macchina?”

Trace, span e log individuali hanno anche un’opzione “Export JSON” nei menu contestuali. Devi condividere una trace specifica? Click destro, copia JSON, incolla nella descrizione della PR. Fatto.

L’API di telemetria è il vero punto di svolta

Questo è ciò che mi entusiasma di più. La dashboard ora espone un’API HTTP sotto /api/telemetry per interrogare i dati di telemetria programmaticamente. Endpoint disponibili:

GET /api/telemetry/resources — elencare risorse con telemetria
GET /api/telemetry/spans — interrogare span con filtri
GET /api/telemetry/logs — interrogare log con filtri
GET /api/telemetry/traces — elencare trace
GET /api/telemetry/traces/{traceId} — ottenere tutti gli span per una trace specifica

Tutto torna in formato OTLP JSON. Questo alimenta i nuovi comandi CLI aspire agent mcp e aspire otel, ma l’implicazione reale è più grande: ora puoi costruire strumenti, script e integrazioni con agenti IA che interrogano direttamente la telemetria della tua app.

Immagina un agente IA che può vedere le tue trace distribuite reali durante il debug. Non è più ipotetico — è ciò che questa API rende possibile.

La telemetria GenAI diventa pratica

Se stai costruendo app con IA usando Semantic Kernel o Microsoft.Extensions.AI, apprezzerai il visualizzatore di telemetria GenAI migliorato. Aspire 13.2 aggiunge:

Descrizioni degli strumenti IA renderizzate come Markdown
Un pulsante GenAI dedicato nella pagina delle trace per accesso rapido
Migliore gestione errori per JSON GenAI troncato o non standard
Navigazione click-to-highlight tra le definizioni degli strumenti

Il post menziona che VS Code Copilot chat, Copilot CLI e OpenCode supportano tutti la configurazione di un OTEL_EXPORTER_OTLP_ENDPOINT. Puntali alla dashboard Aspire e puoi letteralmente guardare i tuoi agenti IA pensare in tempo reale attraverso la telemetria. Questa è un’esperienza di debug che non troverai da nessun’altra parte.

Per concludere

Aspire 13.2 trasforma la dashboard da “bella UI di debug” a “piattaforma di osservabilità programmabile”. Il flusso di esportazione/importazione da solo fa risparmiare tempo reale nel debug distribuito, e l’API di telemetria apre la porta alla diagnostica assistita dall’IA.

Se sei già su Aspire, aggiorna. Se no — questa è una buona ragione per dare un’occhiata a aspire.dev.

Aspire | The .NET Blog

Endpoint Privati, VNet, NSG — Aspire Gestisce la Rete Ora

I Blocchi di Costruzione

Descrivendolo nel tuo AppHost

Perché Questo è Importante per le Applicazioni Reali

Conclusione

Aspire 13.3: Supporto Kubernetes, Log del Browser e la Skill Aspireify

Aspireify: Onboarding Assistito da Agente

Deployment di Kubernetes e AKS di Prima Classe

Log del Browser nel Dashboard

Risultati dei Comandi Strutturati

Conclusione

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

Bun è Ora di Prima Classe

Yarn Più Affidabile

Miglioramenti ai Container

Miglioramenti al Debug

Global Azure Spain 2026

Punti salienti dell’agenda

Biglietti

Azure Tour 2026

Smetti di sorvegliare il tuo terminale: la modalità detached di Aspire cambia il flusso di lavoro

Modalità detached: un comando, terminale recuperato

Gestire ciò che è in esecuzione

Combinalo con la modalità isolata

Perché questo è enorme per gli agenti di codice

Per concludere

.NET Aspire 13.2 Vuole Essere il Migliore Amico del Tuo Agente IA

Il problema è reale

Aspire come infrastruttura per agenti

L’analogia dei parabordi del bowling

Per iniziare

Per concludere

La Modalità Isolata di Aspire Risolve l'Incubo dei Conflitti di Porta per lo Sviluppo Parallelo

La soluzione: --isolated

Scenari reali dove questo brilla

Come funziona sotto il cofano

Quando usarlo

Per concludere

Aspire 13.2 include una CLI per la documentazione — e anche il tuo agente IA può usarla

Il problema che questo risolve davvero

Tre comandi, zero schede del browser

Elencare tutta la documentazione

Cercare un argomento

Leggere una pagina intera (o solo una sezione)

L’aspetto agente IA

Scenari reali

La documentazione è sempre aggiornata

Per concludere

La Dashboard di Aspire 13.2 ora ha un'API di telemetria — e cambia tutto

Esportare telemetria come una persona normale

L’API di telemetria è il vero punto di svolta

La telemetria GenAI diventa pratica

Per concludere

La soluzione: `--isolated`