<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with aspire]]></title><description><![CDATA[A list of topics that have been tagged with aspire]]></description><link>https://forum.androidiani.net/tags/aspire</link><generator>RSS for Node</generator><lastBuildDate>Fri, 01 May 2026 00:36:10 GMT</lastBuildDate><atom:link href="https://forum.androidiani.net/tags/aspire.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 13 Apr 2026 13:42:44 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[.NET Aspire 13.2: la modalità isolata risolve i conflitti di porta nello sviluppo parallelo]]></title><description><![CDATA[Chiunque abbia lavorato con .NET Aspire su progetti reali si è prima o poi scontrato con il classico errore: “Port 17370 is already in use”. Capita quando si prova ad avviare una seconda istanza dell’AppHost — magari su un altro branch, o in un altro terminale — e le porte predefinite sono già occupate dalla prima istanza in esecuzione. Con Aspire 13.2, questo problema ha finalmente una soluzione elegante: la modalità isolata (--isolated).In questo articolo vediamo nel dettaglio come funziona questa nuova funzionalità, i casi d’uso pratici, e le altre novità rilevanti di questa release.Il problema: conflitti di porta nello sviluppo paralleloIn un tipico progetto .NET Aspire, l’AppHost configura i binding delle porte per tutti i servizi nell’orchestrazione: la dashboard su una porta, l’API su un’altra, il database su un’altra ancora. Questi binding sono statici per default, e questo crea problemi immediati quando si vuole eseguire due istanze dello stesso AppHost contemporaneamente:Sviluppo su due branch in parallelo con git worktreesTest di integrazione che richiedono un AppHost “live” mentre si continua a sviluppareAgenti AI che creano automaticamente worktree separati per task paralleliPipeline CI/CD locali che eseguono più istanze dello stesso progettoLa soluzione tradizionale era modificare manualmente i port binding nella configurazione — un approccio fragile, soggetto a errori e difficile da gestire in team.La soluzione: la flag --isolatedAspire 13.2 introduce la flag --isolated che risolve il problema alla radice. L’utilizzo è semplicissimo:aspire run --isolated # oppure aspire start --isolatedQuando si passa --isolated, la CLI genera un identificativo univoco per l’istanza corrente, e questo ID guida due comportamenti fondamentali:1. Randomizzazione automatica delle porteInvece di usare le porte definite staticamente nell’AppHost, ogni istanza isolata riceve un range di porte casuali disponibili. Dove un run normale potrebbe bindare i servizi su 8080, 8081, 8082, due istanze isolate potrebbero usare rispettivamente:Istanza 1: 15234, 15235, 15236Istanza 2: 22891, 22892, 22893La cosa notevole è che il codice dell’applicazione non necessita alcuna modifica: il service discovery di Aspire risolve gli endpoint dinamicamente a runtime, quindi i servizi si “trovano” a prescindere dalle porte assegnate.2. Isolamento dei user secretsLa configurazione rimane completamente separata per ogni istanza. Connection string, chiavi API e altre variabili d’ambiente non si “contaminano” tra run diversi, anche quando puntano a risorse Azure o database con nomi diversi. Questo è particolarmente importante in scenari di test dove ogni istanza deve operare in modo completamente autonomo.Casi d’uso praticiGit worktrees multipliIl caso d’uso più comune: sviluppo su due branch in parallelo.# Terminale 1 - branch principale cd ~/projects/myapp-main aspire run --isolated  # Terminale 2 - feature branch cd ~/projects/myapp-feature-xyz aspire run --isolatedEntrambe le istanze partono senza conflitti, con porte diverse assegnate automaticamente. La dashboard di Aspire di ciascuna istanza è accessibile su porte diverse, e i servizi di ciascuna istanza sono completamente separati.Test di integrazione con AppHost liveUn pattern molto utile: eseguire test di integrazione contro un AppHost “live” mentre si continua a sviluppare sull’AppHost principale.# AppHost per sviluppo interattivo aspire run --isolated  # In un altro terminale: avvia i test che usano il loro AppHost dedicato dotnet test --isolated-apphostCon la modalità isolata, i test non interferiscono con l’ambiente di sviluppo e viceversa.Sviluppo agenticoQuesto è il caso d’uso che ha spinto direttamente lo sviluppo di questa feature. Gli agenti AI in VS Code Copilot possono creare automaticamente git worktree separati per task paralleli. Con --isolated, ogni agente può avviare il proprio AppHost nella sua directory di lavoro senza conflitti con la sessione principale dello sviluppatore.Aspire 13.2 include anche il comando aspire agent init (rinominato da aspire mcp init) che configura automaticamente gli agenti per usare --isolated con i worktree git.Nuovi comandi CLI in Aspire 13.2La modalità isolata non è l’unica novità della CLI. Aspire 13.2 introduce una serie di nuovi comandi operativi che rendono la gestione delle istanze molto più potente:aspire ps — lista delle istanze attiveElenca tutti gli AppHost Aspire in esecuzione sulla macchina, con le relative informazioni (porte, stato, ID istanza). Utile specialmente quando si hanno più istanze isolate attive contemporaneamente e si vuole sapere cosa sta girando.aspire ps # Output: # ID           PROJECT          STATUS    DASHBOARD # abc123       myapp-main       Running   http://localhost:15234 # def456       myapp-feature    Running   http://localhost:22891aspire describe — dettagli sulle risorseAccede ai dettagli di una risorsa specifica direttamente dal terminale, senza dover aprire la dashboard:aspire describe api # Mostra endpoint, variabili d'ambiente, stato health, ecc.aspire doctor — diagnostica dell’ambienteEsegue un controllo completo dell’ambiente di sviluppo: verifica che tutte le dipendenze siano installate correttamente (Docker, .NET SDK, ecc.) e segnala eventuali problemi di configurazione.aspire wait — attesa su uno stato specificoBlocca l’esecuzione in script di automazione finché una risorsa non raggiunge uno stato specifico. Utile in pipeline CI/CD o in script di startup:aspire run --isolated &amp; aspire wait --resource api --state Running # Ora l'API è sicuramente up, posso eseguire i testaspire export — export di telemetria e datiCattura telemetria e dati delle risorse in formato JSON per analisi offline o per integrazione con altri strumenti.TypeScript AppHost in previewUna delle novità più interessanti di Aspire 13.2 è il supporto preview per scrivere l’AppHost in TypeScript. Fino ad ora, l’AppHost era necessariamente un progetto C#. Con questa release, è possibile usare TypeScript con una sintassi idiomatica:import { createBuilder } from '@aspire/hosting';  const builder = await createBuilder();  // Aggiunge Redis come risorsa const cache = await builder.addRedis("cache");  // Aggiunge un servizio Node.js con dipendenza da Redis const api = await builder.addNpmApp("api", "../api")     .withReference(cache);  await builder.build().run();Il TypeScript AppHost funziona come un processo guest che comunica tramite JSON-RPC con l’orchestrator .NET sottostante. La CLI gestisce automaticamente la generazione degli SDK TypeScript quando si esegue aspire add, e aspire restore li rigenera se necessario.Questa funzionalità è ancora in preview e non è raccomandata per produzione, ma è un segnale chiaro della direzione che sta prendendo Aspire: abbracciare anche gli sviluppatori TypeScript/Node.js, non solo quelli .NET.Miglioramenti alla dashboardExport e import di telemetriaLa dashboard introduce un dialog centralizzato “Manage logs and telemetry” che permette di:Esportare risorse e telemetria come JSONEsportare variabili d’ambiente come file .envImportare dati da sessioni precedentiAPI HTTP per telemetriaNuovo endpoint /api/telemetry sulla dashboard che permette query programmatiche dei dati di telemetria con supporto streaming NDJSON. Utile per integrare la telemetria di Aspire con strumenti di monitoring esterni o script di analisi.Impostazione parametri dalla UIÈ ora possibile impostare i parametri delle risorse direttamente dalla dashboard, con opzione di salvataggio nei user secrets. Questo elimina la necessità di modificare manualmente i file di configurazione per cambiare un parametro durante il debug.Miglioramenti al visualizzatore GenAIChi usa Aspire con workload AI troverà utili i miglioramenti al GenAI visualizer: migliore gestione di schemi complessi, payload troncati, testo non-ASCII e navigazione tra definizioni di tool.Altre novità rilevantiEndpoint MCP per i serviziÈ possibile dichiarare server Model Context Protocol (MCP) direttamente nell’AppHost con il nuovo metodo WithMcpServer():var api = builder.AddProject&lt;Projects.MyApi&gt;("api")     .WithMcpServer("/mcp");Aspire gestirà automaticamente la discovery dell’endpoint MCP, rendendolo disponibile agli agenti AI che operano nell’ambiente.Docker Compose publishing stabileL’integrazione con Docker Compose passa da prerelease a stabile. È ora possibile generare un docker-compose.yaml completo direttamente dal modello di app Aspire con aspire publish --format docker-compose.Azure Virtual NetworkNuovo pacchetto Aspire.Hosting.Azure.Network per la gestione di reti virtuali Azure:var vnet = builder.AddAzureVirtualNetwork("vnet"); var subnet = vnet.AddSubnet("web", "10.0.1.0/24"); var natGateway = vnet.AddNatGateway("nat"); Breaking changes da tenere a menteSe stai aggiornando un progetto Aspire esistente a 13.2, ci sono alcune breaking changes da considerare:Variabili Service Discovery: usano ora lo schema endpoint invece del nome endpointFile di configurazione: preferenza per aspire.config.json unificato (migrazione automatica al primo run)Comandi risorse: resource-start → start, resource-stop → stopDashboard API: ora opt-in per dashboard standalonePacchetto AIFoundry: Aspire.Hosting.Azure.AIFoundry → Aspire.Hosting.FoundryWithSecretBuildArg: rinominato in WithBuildSecretPer aggiornare, usa:aspire update --self   # aggiorna la CLI aspire update          # aggiorna i pacchetti del progettoConclusioneAspire 13.2 è una release sostanziosa che affronta problemi concreti del workflow di sviluppo. La modalità --isolated è probabilmente la novità più impattante per il day-to-day: risolve un pain point reale in modo elegante, senza richiedere modifiche al codice dell’applicazione.L’aggiunta del TypeScript AppHost in preview è un segnale importante della direzione di Aspire verso un ecosistema più inclusivo, mentre i nuovi comandi CLI (ps, describe, doctor, wait) rendono Aspire molto più adatto a workflow di automazione e sviluppo agentico.Chi lavora già con Aspire troverà questo aggiornamento decisamente consigliato. Chi non lo ha ancora provato, potrebbe essere il momento giusto per iniziare — soprattutto se lavora con architetture microservizi in .NET.Fonti: Running Multiple Instances of an Aspire AppHost Without Port Conflicts · What’s new in Aspire 13.2]]></description><link>https://forum.androidiani.net/topic/515087a3-6537-4ff3-9a75-f1e4bc491841/.net-aspire-13.2-la-modalità-isolata-risolve-i-conflitti-di-porta-nello-sviluppo-parallelo</link><guid isPermaLink="true">https://forum.androidiani.net/topic/515087a3-6537-4ff3-9a75-f1e4bc491841/.net-aspire-13.2-la-modalità-isolata-risolve-i-conflitti-di-porta-nello-sviluppo-parallelo</guid><dc:creator><![CDATA[blog@spcnet.it]]></dc:creator><pubDate>Mon, 13 Apr 2026 13:42:44 GMT</pubDate></item></channel></rss>