Aspire | The .NET Blog

Private Endpoints, VNets, NSGs — Aspire übernimmt jetzt das Netzwerk

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

Ich habe dieses Szenario zu oft gesehen. Die App ist fertig. Die Demo ist großartig. Dann erscheint die Sicherheits-Checkliste: Speicher aus dem öffentlichen Internet nehmen, innerhalb eines VNets ausführen, ausgehende IPs für die Allowlist des Partners bereitstellen, nachweisen, dass nur die richtigen Subnetze mit den richtigen Diensten kommunizieren.

An diesem Punkt beginnen das Anwendungsmodell und das Infrastrukturmodell auseinanderzudriften, auf eine Art, die schmerzhaft zu pflegen ist.

Der neue Azure-Unternehmensnetzwerk-Support für Aspire adressiert dies direkt. Sie beschreiben die Netzwerkstruktur neben den Ressourcen, die sie verwenden, in Ihrem AppHost.

Die Bausteine

Hier ist, wofür jedes Azure-Netzwerkkonzept verwendet wird, destilliert:

Funktion	Verwenden Sie es wenn	Warum es wichtig ist
Virtuelles Netzwerk	Sie einen privaten Adressraum benötigen	Die Netzwerkgrenze für Subnetze, private Endpoints und Routing
Subnetz	Sie Workloads innerhalb des VNets trennen müssen	Jeder Teil des Systems erhält seinen eigenen Adressbereich und seine eigene Richtlinienoberfläche
Delegiertes Subnetz	Ein Plattformdienst (wie ACA) ein Subnetz verwalten muss	Ermöglicht dem Dienst, verwaltete Infrastruktur sicher in Ihrem VNet zu platzieren
NAT-Gateway	Sie vorhersagbare ausgehende öffentliche IPs benötigen	Stabile Adresse für Allowlists und Auditing
Privater Endpoint	Sie eine PaaS-Ressource privat erreichbar haben möchten	Platziert eine private IP für diesen Dienst in Ihrem VNet, entfernt öffentliche Exposition
NSG	Sie Regeln für Datenverkehr auf Subnetz-Ebene benötigen	Explizites Erlauben/Ablehnen für eingehenden und ausgehenden Datenverkehr pro Subnetz

Beschreibung im AppHost

Die wichtigste Änderung hier ist, dass Sie das Netzwerk zusammen mit den Ressourcen modellieren, die es verwenden, nicht in einer separaten Bicep-Datei, die mit der Zeit vom Anwendungsmodell abweicht.

Vom AppHost aus können Sie:

VNets und Subnetze mit AddVirtualNetwork() und AddSubnet() erstellen
Ein NAT-Gateway an Subnetze für stabile ausgehende IPs anhängen
Private Endpoints für Speicher, Key Vault, SQL und andere PaaS-Dienste erstellen
NSGs mit eingehenden und ausgehenden Sicherheitsregeln definieren
Netzwerksicherheitsperimeter für ressourcenübergreifende Richtlinien konfigurieren

Das Ergebnis ist, dass wenn Sie azd up ausführen, die Infrastruktur mit dem übereinstimmt, was das Anwendungsmodell sagt, dass es benötigt. Nicht das, was eine manuell gepflegte Vorlage sagt.

Warum das für echte Anwendungen wichtig ist

Einige Dinge, die erheblich einfacher werden, sobald das Netzwerk in Aspire modelliert ist:

Private Endpoints für Key Vault und Speicher — Sie beschreiben WithPrivateEndpoint() auf diesen Ressourcen, und Aspire übernimmt die DNS-Zonenkonfiguration und das Endpoint-Anhängen. Die App ändert sich nie.

Konsistente ausgehende IPs — fügen Sie ein NAT-Gateway zum entsprechenden Subnetz hinzu, und jede ausgehende Anfrage Ihrer App geht durch eine bekannte, stabile IP. Partner können sie allowlisten. Auditoren können sie nachverfolgen.

NSG-Regeln aus Code — anstatt durch das Portal zu klicken oder ein Bicep-Snippet zu pflegen, leben Ihre Sicherheitsregeln im AppHost neben den Ressourcen, die sie schützen.

Dies ist die Art von Integration, die Demos nicht aufregend macht, aber Produktionssysteme wartbar macht.

Fazit

Netzwerksicherheit, die spät im Projektlebenszyklus auftaucht, ist ein gelöstes Problem, wenn Sie sie von Anfang an zusammen mit der App modellieren. Der Unternehmensnetzwerk-Support von Aspire macht das möglich, ohne eine separate Infrastruktur-Spur zu benötigen.

Vollständige Details im ursprünglichen Beitrag: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Kubernetes-Unterstützung, Browser-Logs und die Aspireify-Funktion

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

Fünf Wochen sind keine lange Zeit für ein Release, aber Aspire 13.3 fühlt sich nicht so an. Die Hauptpunkte sind bedeutsam: erstklassiges Kubernetes- und AKS-Deployment mit Helm, eine agentengestützte Onboarding-Funktion namens Aspireify, Browser-Log-Erfassung direkt im Dashboard und strukturierte Befehlsergebnisse. Dazu 45 neue Features, 134 Verbesserungen und 93 Fehlerbehebungen.

Kommen wir zu den Highlights.

Aspireify: Agentengestütztes Onboarding

Aspire zu einem bestehenden Projekt hinzuzufügen klingt einfach — AppHost einfügen, fertig. In der Praxis erfordert es viel Recherche: welche Ports wichtig sind, welche Umgebungsvariablen echte Abhängigkeiten sind, welche Docker-Compose-Dienste zu Aspire-Integrationen zugeordnet werden sollen.

Die neue Aspireify-Funktion gibt Ihrem Coding-Agenten einen geführten Workflow genau dafür. Wenn aspire init einen Skelett-AppHost erstellt, hilft die Aspireify-Funktion dem Agenten, das Repository zu inspizieren, zu verstehen, wie es bereits funktioniert, und den AppHost so zu verdrahten, dass er zur App passt — nicht umgekehrt.

Die Standardhaltung ist “Änderungen an Ihrem Code minimieren.” Wenn Ihre App bereits DATABASE_URL liest, mappt der Agent das mit WithEnvironment() anstatt Sie zu bitten, Ihre Konfiguration neu zu schreiben. Wenn ein Port fest codiert ist, teilt die Funktion dem Agenten mit, wann er ihn beibehalten soll.

Das ist die Art von KI-Tooling, die wirklich Zeit spart, anstatt mehr Arbeit zum Überprüfen zu generieren.

Erstklassiges Kubernetes- und AKS-Deployment

Dies stand schon eine Weile auf der Wunschliste. Aspire 13.3 liefert erstklassige Kubernetes- und AKS-Deployment-Unterstützung mit Helm. Sie können jetzt AKS direkt aus den Aspire-Tools als Deployment-Ziel wählen.

Für Teams, die bereits Produktionsworkloads auf AKS betreiben, schließt dies eine bedeutende Lücke. Ihr Aspire-App-Modell hat jetzt einen sauberen Weg von der lokalen Entwicklung zu Kubernetes ohne manuelle Helm-Chart-Erstellung.

Browser-Logs im Dashboard

Das ist eine jener Funktionen, die klein erscheinen, bis man ein Frontend-Problem debuggt.

Die neue WithBrowserLogs() API hängt eine verfolgte Browser-Ressource an jede endpoint-fähige Ressource an. Aspire startet Chromium mit einer privaten CDP-Pipe und streamt Konsolen-Logs, Netzwerkanfragen und Fehler direkt in den Ressourcen-Log-Stream:

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

Der TypeScript AppHost unterstützt dasselbe:

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

Konsolen-Fehler, fehlgeschlagene Netzwerkanfragen, clientseitige Ausnahmen — alles im selben Dashboard sichtbar, wo Sie bereits Traces und Metriken beobachten. Kein Tab-Wechsel zu Browser DevTools mehr für die Grundlagen.

Strukturierte Befehlsergebnisse

Ressourcenbefehle haben ein bedeutsames Upgrade erhalten. Bisher gaben Befehle Erfolg/Misserfolg zurück. Jetzt geben sie strukturierte Ergebnisse zurück: Text, JSON oder Markdown, das durch das Modell, die Dashboard-Benutzeroberfläche, die CLI und die MCP-Tools fließt.

Das Dashboard verbindet all das mit einem neuen Benachrichtigungscenter im Header. Befehlsergebnisse erscheinen als zeitgestempelte Benachrichtigungen mit Markdown-Rendering und einer “Antwort anzeigen”-Aktion.

Das macht Ressourcenbefehle wirklich komposierbar. Eine Integration kann jetzt einen Befehl exponieren, der eine bedeutsame Ausgabe zurückgibt — wie eine Tunnel-URL — anstatt nur irgendwo den Zustand zu ändern.

Fazit

Aspire 13.3 ist das Upgrade wert, allein schon für die Kubernetes-Unterstützung. Die Browser-Logs und strukturierten Befehlsergebnisse fühlen sich wie die Art von Verbesserungen der Lebensqualität an, die sich in einem alltäglichen Entwicklungsworkflow schnell ansammeln.

Vollständige Versionshinweise: What’s New in Aspire 13.3

Aspire 13.2: Bun-Support, bessere Container und weniger Debug-Reibung

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

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Wenn du .NET-Backends mit JavaScript-Frontends in Aspire baust, ist 13.2 das Update, das deinen Alltag leise besser macht. Keine neuen Paradigmen. Nur solide Verbesserungen an Dingen, die leicht nervig waren.

Bun ist jetzt erstklassig

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

Wenn dein Team Bun bereits verwendet, zwingt Aspire dich nicht mehr gegen den Strom zu schwimmen.

Yarn wurde zuverlässiger

Yarn-Nutzer bekommen etwas mindestens genauso Wichtiges: weniger mysteriöse Fehler bei withYarn() mit addViteApp().

Container-Verbesserungen

Explizite Pull Policy

const worker = await builder.addContainer("worker", "myorg/worker:latest")
 .withImagePullPolicy(ImagePullPolicy.Never);

Perfekt für Workflows, wo du lokal Images baust und Compose genau dieses verwenden soll.

PostgreSQL 18+ funktioniert korrekt

PostgreSQL 18 änderte sein internes Verzeichnislayout, was das Volume-Mapping still brach. 13.2 behebt das.

Debugging-Verbesserungen

DebuggerDisplayAttribute auf Core-Typen — nützliche Werte statt tiefer Objektbäume
Bessere Fehlermeldungen für WaitFor
BeforeResourceStartedEvent feuert zum richtigen Zeitpunkt

Fazit

Aspire 13.2 ist ein fokussiertes Qualitäts-Release. Originalpost von 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 findet am 18. April 2026 im Kinépolis Diversia in Alcobendas, Madrid statt. Es ist das größte Community-Azure-Event in Spanien, mit 38 Speakern auf 3 parallelen Tracks zu KI-Agenten, Azure-Netzwerken, Cosmos DB, Fabric, IoT, Sicherheit und vielem mehr.

Das Event läuft von 08:30 bis 18:30 und beinhaltet Keynote, Kaffeepausen, Mittagessen und eine Abschluss-Q&A-Session.

Highlights der Agenda

Domando Agentes de IA: Governance, Tools und APIs mit Azure AI Foundry und 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!: Multi-Agenten-Systeme in Aktion
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Tickets

Die Anmeldung erfolgt als symbolische Spende — der gesamte Ticketpreis geht direkt an Plan International für Kinderrechte und Gleichstellung weltweit. Begrenzte Kapazität, also sicher dir rechtzeitig einen Platz.

Azure Tour 2026

Neben Madrid umfasst die Global Azure Tour 2026 auch Stationen in Zaragoza, Teneriffa und Sevilla.

Hör auf, dein Terminal zu babysitzen: Aspires Detached Mode verändert den Workflow

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

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Jedes Mal, wenn du einen Aspire AppHost startest, ist dein Terminal weg. Gesperrt. Belegt, bis du Ctrl+C drückst. Musst du schnell einen Befehl ausführen? Öffne einen neuen Tab. Willst du Logs prüfen? Noch ein Tab. Es ist eine kleine Reibung, die sich schnell summiert.

Aspire 13.2 behebt das. James Newton-King hat alle Details aufgeschrieben, und ehrlich gesagt ist das eines dieser Features, das sofort verändert, wie man arbeitet.

Detached Mode: ein Befehl, Terminal zurück

aspire start

Das ist die Kurzform für aspire run --detach. Dein AppHost startet im Hintergrund und du bekommst dein Terminal sofort zurück. Keine Extra-Tabs. Kein Terminal-Multiplexer. Einfach dein Prompt, bereit loszulegen.

Laufende Prozesse verwalten

Die Sache ist — im Hintergrund laufen lassen ist nur nützlich, wenn man auch verwalten kann, was da draußen läuft. Aspire 13.2 liefert einen vollständigen Satz an CLI-Befehlen genau dafür:

# 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

Das macht die Aspire CLI zu einem echten Prozessmanager. Du kannst mehrere AppHosts starten, ihren Status prüfen, ihre Logs verfolgen und sie herunterfahren — alles aus einer einzigen Terminal-Sitzung.

Kombiniere es mit dem isolierten Modus

Der Detached Mode passt natürlich zum isolierten Modus. Willst du zwei Instanzen desselben Projekts im Hintergrund ohne Port-Konflikte laufen lassen?

aspire start --isolated
aspire start --isolated

Jede bekommt zufällige Ports, separate Secrets und ihren eigenen Lebenszyklus. Verwende aspire ps, um beide zu sehen, aspire stop, um den zu beenden, den du nicht mehr brauchst.

Warum das für Coding-Agents riesig ist

Hier wird es richtig interessant. Ein Coding-Agent, der in deinem Terminal arbeitet, kann jetzt:

Die App mit aspire start starten
Ihren Zustand mit aspire describe abfragen
Logs mit aspire logs prüfen, um Probleme zu diagnostizieren
Sie mit aspire stop beenden, wenn er fertig ist

Alles ohne die Terminal-Sitzung zu verlieren. Vor dem Detached Mode hätte sich ein Agent, der deinen AppHost ausführt, aus seinem eigenen Terminal ausgesperrt. Jetzt kann er starten, beobachten, iterieren und aufräumen — genau so, wie man es von einem autonomen Agenten erwartet.

Das Aspire-Team hat hier bewusst investiert. aspire agent init richtet eine Aspire-Skill-Datei ein, die Agents diese Befehle beibringt. So können Tools wie Copilots Coding-Agent deine Aspire-Workloads direkt verwalten.

Fazit

Der Detached Mode ist ein Workflow-Upgrade, das sich als einfaches Flag tarnt. Du hörst auf, zwischen Terminals zu wechseln, Agents blockieren sich nicht mehr selbst, und die neuen CLI-Befehle geben dir echte Sichtbarkeit über das, was läuft. Es ist praktisch, es ist sauber, und es macht den täglichen Entwicklungszyklus spürbar flüssiger.

Lies den vollständigen Beitrag für alle Details und hole dir Aspire 13.2 mit aspire update --self.

.NET Aspire 13.2 Will der Beste Freund Deines KI-Agenten Sein

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

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Kennst du den Moment, wenn dein KI-Agent soliden Code schreibt, du begeistert bist, und dann alles zusammenbricht, wenn er versucht, das Ding tatsächlich auszuführen? Port-Konflikte, Geister-Prozesse, falsche Umgebungsvariablen — plötzlich verbrennt dein Agent Tokens beim Troubleshooting von Startproblemen statt Features zu bauen.

Das Aspire-Team hat gerade einen wirklich durchdachten Post über genau dieses Problem veröffentlicht, und ihre Antwort ist überzeugend: Aspire 13.2 ist nicht nur für Menschen konzipiert, sondern auch für KI-Agenten.

Das Problem ist real

KI-Agenten sind unglaublich gut im Code schreiben. Aber eine funktionierende Full-Stack-App zu liefern, erfordert viel mehr als nur Dateien zu generieren. Du musst Services in der richtigen Reihenfolge starten, Ports verwalten, Umgebungsvariablen setzen, Datenbanken verbinden und Feedback bekommen, wenn etwas kaputt geht. Im Moment handhaben die meisten Agenten all das durch Trial-and-Error — Befehle ausführen, Fehlerausgaben lesen, es nochmal versuchen.

Wir packen Markdown-Anleitungen, Custom Skills und Prompts drauf, um sie zu leiten, aber die sind unvorhersehbar, können nicht kompiliert werden und kosten Tokens allein zum Parsen. Das Aspire-Team hat den Kern erkannt: Agenten brauchen Compiler und strukturierte APIs, nicht mehr Markdown.

Aspire als Agenten-Infrastruktur

Das bringt Aspire 13.2 für die agentische Entwicklung mit:

Dein gesamter Stack in typisiertem Code. Der AppHost definiert deine komplette Topologie — API, Frontend, Datenbank, Cache — in kompilierbarem TypeScript oder C#:

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();

Ein Agent kann das lesen, um die App-Topologie zu verstehen, Ressourcen hinzuzufügen, Verbindungen zu verkabeln und zum Verifizieren zu kompilieren. Der Compiler sagt ihm sofort, wenn etwas falsch ist. Kein Raten, kein Trial-and-Error mit Konfigurationsdateien.

Ein Befehl um sie alle zu starten. Statt dass Agenten docker compose up, npm run dev und Datenbank-Startskripte jonglieren, ist alles einfach aspire start. Alle Ressourcen starten in der richtigen Reihenfolge, auf den richtigen Ports, mit der richtigen Konfiguration. Langlebige Prozesse blockieren den Agenten auch nicht — Aspire verwaltet sie.

Isolierter Modus für parallele Agenten. Mit --isolated bekommt jeder Aspire-Lauf eigene zufällige Ports und separate User Secrets. Mehrere Agenten arbeiten über Git Worktrees hinweg? Sie kollidieren nicht. Das ist riesig für Tools wie VS Codes Background-Agenten, die parallele Umgebungen aufspannen.

Agenten-Augen durch Telemetrie. Hier wird es richtig mächtig. Die Aspire CLI stellt während der Entwicklung volle OpenTelemetry-Daten bereit — Traces, Metriken, strukturierte Logs. Dein Agent liest nicht einfach Konsolenausgaben und hofft das Beste. Er kann eine fehlgeschlagene Anfrage über Services hinweg tracen, langsame Endpunkte profilen und genau identifizieren, wo Dinge kaputtgehen. Das ist Observability auf Produktionsniveau in der Entwicklungsschleife.

Die Bowlingbahn-Bumper-Analogie

Das Aspire-Team nutzt eine großartige Analogie: Denk an Aspire als Bowlingbahn-Bumper für KI-Agenten. Wenn der Agent nicht perfekt ist (und das wird er nicht sein), verhindern die Bumper, dass er Rinnenschüsse wirft. Die Stack-Definition verhindert Fehlkonfiguration, der Compiler fängt Fehler, die CLI übernimmt das Prozessmanagement, und die Telemetrie liefert die Feedback-Schleife.

Kombiniere das mit etwas wie Playwright CLI, und dein Agent kann deine App tatsächlich benutzen — durch Flows klicken, das DOM prüfen, kaputte Dinge in der Telemetrie sehen, den Code fixen, neustarten und erneut testen. Bauen, ausführen, beobachten, fixen. Das ist die autonome Entwicklungsschleife, die wir verfolgt haben.

Erste Schritte

Neu bei Aspire? Installiere die CLI von get.aspire.dev und folge dem Getting-Started-Guide.

Nutzt du Aspire bereits? Führe aspire update --self aus, um Version 13.2 zu bekommen, und zeige dann deinem Lieblings-Coding-Agenten dein Repo. Du wirst überrascht sein, wie viel weiter er mit Aspires Leitplanken kommt.

Zusammenfassung

Aspire 13.2 ist nicht mehr nur ein Framework für verteilte Apps — es wird zur essentiellen Agenten-Infrastruktur. Strukturierte Stack-Definitionen, Ein-Befehl-Start, isolierte parallele Ausführungen und Echtzeit-Telemetrie geben KI-Agenten genau das, was sie brauchen, um vom Code-Schreiben zum App-Liefern zu kommen.

Lies den vollständigen Post vom Aspire-Team für alle Details und Demo-Videos.

Aspires Isolierter Modus Behebt den Port-Konflikt-Albtraum für Parallele Entwicklung

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

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Wenn du jemals versucht hast, zwei Instanzen desselben Projekts gleichzeitig zu starten, kennst du den Schmerz. Port 8080 wird bereits verwendet. Port 17370 ist belegt. Etwas killen, neustarten, Umgebungsvariablen jonglieren — ein echter Produktivitätskiller.

Dieses Problem wird schlimmer, nicht besser. KI-Agenten erstellen Git Worktrees um unabhängig zu arbeiten. Hintergrund-Agenten starten separate Umgebungen. Entwickler checken dasselbe Repo zweimal für Feature-Branches aus. Jedes dieser Szenarien läuft gegen dieselbe Wand: Zwei Instanzen derselben App kämpfen um dieselben Ports.

Aspire 13.2 behebt das mit einem einzigen Flag. James Newton-King vom Aspire-Team hat alle Details aufgeschrieben, und es ist eines dieser „warum hatten wir das nicht schon früher"-Features.

Die Lösung: `--isolated`

aspire run --isolated

Das war’s. Jeder Lauf bekommt:

Zufällige Ports — keine Kollisionen mehr zwischen Instanzen
Isolierte User Secrets — Connection Strings und API Keys bleiben pro Instanz getrennt

Keine manuelle Port-Neuzuweisung. Kein Umgebungsvariablen-Jonglieren. Jeder Lauf bekommt automatisch eine frische, kollisionsfreie Umgebung.

Reale Szenarien, in denen das glänzt

Mehrere Checkouts. Du hast einen Feature-Branch in einem Verzeichnis und einen Bugfix in einem anderen:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Beide laufen ohne Konflikte. Das Dashboard zeigt, was wo läuft.

Hintergrund-Agenten in VS Code. Wenn der Hintergrund-Agent von Copilot Chat einen Git Worktree erstellt um unabhängig an deinem Code zu arbeiten, muss er möglicherweise deinen Aspire AppHost starten. Ohne --isolated ist das ein Port-Konflikt mit deinem primären Worktree. Mit ihm funktionieren einfach beide Instanzen.

Der Aspire-Skill, der mit aspire agent init mitkommt, weist Agenten automatisch an, --isolated zu verwenden, wenn sie in Worktrees arbeiten. So sollte Copilots Hintergrund-Agent das von Haus aus richtig handhaben.

Integrationstests parallel zur Entwicklung. Tests gegen einen laufenden AppHost ausführen während du weiter Features baust? Der isolierte Modus gibt jedem Kontext eigene Ports und Konfiguration.

Wie es unter der Haube funktioniert

Wenn du --isolated übergibst, generiert die CLI eine eindeutige Instanz-ID für den Lauf. Das treibt zwei Verhaltensweisen:

Port-Randomisierung — statt sich an vorhersagbare Ports aus deiner AppHost-Konfiguration zu binden, wählt der isolierte Modus zufällige verfügbare Ports für alles — das Dashboard, Service-Endpoints, alles. Service Discovery passt sich automatisch an, sodass sich Services gegenseitig finden, unabhängig davon, auf welchen Ports sie landen.
Secret-Isolation — jeder isolierte Lauf bekommt seinen eigenen User-Secrets-Speicher, der durch die Instanz-ID identifiziert wird. Connection Strings und API Keys eines Laufs lecken nicht in einen anderen.

Dein Code braucht keine Änderungen. Aspires Service Discovery löst Endpoints zur Laufzeit auf, sodass alles korrekt verbunden wird, unabhängig von der Port-Zuweisung.

Wann man es verwenden sollte

Verwende --isolated, wenn du mehrere Instanzen desselben AppHosts gleichzeitig betreibst — sei es für parallele Entwicklung, automatisierte Tests, KI-Agenten oder Git Worktrees. Für Einzelinstanz-Entwicklung, bei der du vorhersagbare Ports bevorzugst, funktioniert das reguläre aspire run weiterhin bestens.

Zusammenfassung

Der isolierte Modus ist ein kleines Feature, das ein reales, zunehmend häufiges Problem löst. Da KI-gestützte Entwicklung uns in Richtung mehr paralleler Workflows drängt — mehrere Agenten, mehrere Worktrees, mehrere Kontexte — ist die Fähigkeit, einfach eine weitere Instanz hochzufahren ohne um Ports zu kämpfen, essentiell.

Lies den vollständigen Post für alle technischen Details und probiere es aus mit aspire update --self um Version 13.2 zu bekommen.

Aspire 13.2 liefert eine Docs-CLI — und dein KI-Agent kann sie auch nutzen

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Kennst du diesen Moment, wenn du tief in einem Aspire AppHost steckst, Integrationen verdrahtest, und du genau nachschauen musst, welche Parameter die Redis-Integration erwartet? Du wechselst mit Alt-Tab zum Browser, suchst auf aspire.dev, kneifst die Augen zusammen bei den API-Docs, und kommst zurück zu deinem Editor. Kontext verloren. Flow unterbrochen.

Aspire 13.2 hat gerade eine Lösung dafür geliefert. Die aspire docs-CLI ermöglicht es dir, offizielle Aspire-Dokumentation direkt aus deinem Terminal zu suchen, durchstöbern und lesen. Und weil sie auf wiederverwendbaren Services basiert, können KI-Agenten und Skills dieselben Befehle nutzen, um Docs nachzuschlagen, statt APIs zu halluzinieren, die gar nicht existieren.

Das Problem, das hier wirklich gelöst wird

David Pine bringt es im Originalbeitrag auf den Punkt: KI-Agenten waren furchtbar darin, Entwicklern beim Bauen von Aspire-Apps zu helfen. Sie empfahlen dotnet run statt aspire run, verwiesen auf learn.microsoft.com für Docs, die auf aspire.dev leben, schlugen veraltete NuGet-Pakete vor, und — mein persönlicher Favorit — halluzinierten APIs, die nicht existieren.

Warum? Weil Aspire viel länger .NET-spezifisch war, als es polyglott ist, und LLMs mit Trainingsdaten arbeiten, die älter sind als die neuesten Features. Wenn du einem KI-Agenten die Möglichkeit gibst, tatsächlich die aktuellen Docs nachzuschlagen, hört er auf zu raten und wird nützlich.

Drei Befehle, null Browser-Tabs

Die CLI ist erfrischend einfach:

Alle Docs auflisten

aspire docs list

Gibt jede verfügbare Dokumentationsseite auf aspire.dev zurück. Brauchst du maschinenlesbare Ausgabe? Füge --format Json hinzu.

Nach einem Thema suchen

aspire docs search "redis"

Durchsucht sowohl Titel als auch Inhalte mit gewichteter Relevanzbewertung. Dieselbe Suchmaschine, die intern die Dokumentationswerkzeuge antreibt. Du bekommst gerankte Ergebnisse mit Titeln, Slugs und Relevanzwerten.

Eine vollständige Seite lesen (oder nur einen Abschnitt)

aspire docs get redis-integration

Streamt die vollständige Seite als Markdown in dein Terminal. Brauchst du nur einen Abschnitt?

aspire docs get redis-integration --section "Add Redis resource"

Chirurgische Präzision. Kein Scrollen durch 500 Zeilen. Nur der Teil, den du brauchst.

Der KI-Agent-Aspekt

Hier wird es interessant für uns Entwickler, die mit KI-Werkzeugen arbeiten. Dieselben aspire docs-Befehle funktionieren als Tools für KI-Agenten — über Skills, MCP-Server oder einfache CLI-Wrapper.

Statt dass dein KI-Assistent Aspire-APIs auf Basis veralteter Trainingsdaten erfindet, kann er aspire docs search "postgres" aufrufen, die offiziellen Integrations-Docs finden, die richtige Seite lesen und dir den dokumentierten Ansatz liefern. Echtzeit-aktuelle Dokumentation — nicht das, was das Modell vor sechs Monaten auswendig gelernt hat.

Die Architektur dahinter ist bewusst so gestaltet. Das Aspire-Team hat wiederverwendbare Services gebaut (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) anstelle einer einmaligen Integration. Das bedeutet, dieselbe Suchmaschine funktioniert für Menschen im Terminal, KI-Agenten in deinem Editor und Automatisierung in deiner CI-Pipeline.

Praxisszenarien

Schnelle Terminal-Nachschlagen: Du steckst drei Dateien tief und brauchst Redis-Konfigurationsparameter. Zwei Befehle, neunzig Sekunden, zurück an die Arbeit:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

KI-gestützte Entwicklung: Dein VS Code Skill wrapt die CLI-Befehle. Du fragst „Füge eine PostgreSQL-Datenbank zu meinem AppHost hinzu" und der Agent schlägt die echten Docs nach, bevor er antwortet. Keine Halluzinationen.

CI/CD-Validierung: Deine Pipeline validiert AppHost-Konfigurationen programmatisch gegen offizielle Dokumentation. Die --format Json-Ausgabe lässt sich sauber mit jq und anderen Tools weiterverarbeiten.

Eigene Wissensdatenbanken: Baust du deine eigenen KI-Tools? Leite strukturierte JSON-Ausgabe direkt in deine Wissensdatenbank:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Kein Web Scraping. Keine API-Keys. Dieselben strukturierten Daten, die intern von den Dokumentationswerkzeugen genutzt werden.

Die Dokumentation ist immer aktuell

Das ist der Teil, den ich am meisten schätze. Die CLI lädt keinen Snapshot herunter — sie fragt aspire.dev mit ETag-basiertem Caching ab. In dem Moment, in dem die Docs aktualisiert werden, spiegelt deine CLI und jeder darauf aufbauende Skill das wider. Keine veralteten Kopien, keine „aber im Wiki stand doch…"-Momente.

Zum Abschluss

aspire docs ist eines dieser kleinen Features, das ein echtes Problem sauber löst. Menschen bekommen terminal-nativen Dokumentationszugriff. KI-Agenten bekommen eine Möglichkeit, aufzuhören zu raten und stattdessen echte Docs zu referenzieren. Und alles wird von derselben Wahrheitsquelle gespeist.

Wenn du mit .NET Aspire baust und die CLI noch nicht ausprobiert hast, führe aspire docs search "dein-thema-hier" aus und schau, wie es sich anfühlt. Dann überleg dir, diese Befehle in dein KI-Skill- oder Automatisierungs-Setup einzubauen — deine Agenten werden es dir danken.

Schau dir David Pines Deep Dive an, wie die Dokumentationswerkzeuge entstanden sind, und die offizielle CLI-Referenz für alle Details.

Das Aspire 13.2 Dashboard hat jetzt eine Telemetrie-API — und das ändert alles

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wenn du verteilte Apps mit .NET Aspire baust, weißt du bereits, dass das Dashboard das Beste an der ganzen Erfahrung ist. Alle Traces, Logs und Metriken an einem Ort — kein externes Jaeger, kein Seq-Setup, keine „lass mich mal im anderen Terminal schauen"-Momente.

Aspire 13.2 hat es deutlich besser gemacht. James Newton-King hat das Update angekündigt, und ehrlich gesagt? Die Telemetrie-Export- und API-Features allein rechtfertigen das Upgrade.

Telemetrie exportieren wie ein normaler Mensch

Hier ist das Szenario, das wir alle kennen: Du debuggst ein verteiltes Problem, reproduzierst es endlich nach zwanzig Minuten Setup, und jetzt musst du dem Team zeigen, was passiert ist. Vorher? Screenshots. Trace-IDs kopieren und einfügen. Das übliche Chaos.

Aspire 13.2 fügt einen ordentlichen Logs und Telemetrie verwalten-Dialog hinzu, in dem du:

Alle Telemetrie löschen kannst (nützlich vor einem Reproduktionsversuch)
Ausgewählte Telemetrie als ZIP-Datei im Standard-OTLP/JSON-Format exportieren kannst
Diese ZIP-Datei später in jedes Aspire-Dashboard reimportieren kannst

Der letzte Punkt ist das Killer-Feature. Du reproduzierst einen Bug, exportierst die Telemetrie, hängst sie an dein Work Item, und dein Kollege kann sie in sein eigenes Dashboard importieren, um genau das zu sehen, was du gesehen hast. Kein „kannst du das auf deinem Rechner reproduzieren?" mehr.

Einzelne Traces, Spans und Logs haben auch eine „Export JSON"-Option im Kontextmenü. Musst du einen bestimmten Trace teilen? Rechtsklick, JSON kopieren, in die PR-Beschreibung einfügen. Fertig.

Die Telemetrie-API ist der echte Game Changer

Das begeistert mich am meisten. Das Dashboard bietet jetzt eine HTTP-API unter /api/telemetry zum programmatischen Abfragen von Telemetriedaten. Verfügbare Endpunkte:

GET /api/telemetry/resources — Ressourcen mit Telemetrie auflisten
GET /api/telemetry/spans — Spans mit Filtern abfragen
GET /api/telemetry/logs — Logs mit Filtern abfragen
GET /api/telemetry/traces — Traces auflisten
GET /api/telemetry/traces/{traceId} — alle Spans für einen bestimmten Trace abrufen

Alles kommt im OTLP-JSON-Format zurück. Das treibt die neuen CLI-Befehle aspire agent mcp und aspire otel an, aber die wirkliche Bedeutung ist größer: Du kannst jetzt Tooling, Skripte und KI-Agent-Integrationen bauen, die die Telemetrie deiner App direkt abfragen.

Stell dir einen KI-Coding-Agent vor, der deine tatsächlichen verteilten Traces beim Debuggen sehen kann. Das ist nicht mehr hypothetisch — genau das ermöglicht diese API.

GenAI-Telemetrie wird praktisch

Wenn du KI-gestützte Apps mit Semantic Kernel oder Microsoft.Extensions.AI baust, wirst du den verbesserten GenAI-Telemetrie-Visualizer zu schätzen wissen. Aspire 13.2 fügt hinzu:

KI-Toolbeschreibungen als Markdown gerendert
Einen dedizierten GenAI-Button auf der Traces-Seite für schnellen Zugriff
Bessere Fehlerbehandlung für abgeschnittenes oder nicht-standardmäßiges GenAI-JSON
Click-to-Highlight-Navigation zwischen Tool-Definitionen

Der Blogpost erwähnt, dass VS Code Copilot Chat, Copilot CLI und OpenCode alle das Konfigurieren eines OTEL_EXPORTER_OTLP_ENDPOINT unterstützen. Richte sie auf das Aspire-Dashboard und du kannst buchstäblich deinen KI-Agents beim Denken in Echtzeit über Telemetrie zusehen. Das ist ein Debugging-Erlebnis, das du nirgendwo anders findest.

Zusammenfassung

Aspire 13.2 verwandelt das Dashboard von „netter Debugging-UI" zu „programmierbarer Observability-Plattform". Der Export/Import-Workflow allein spart echte Zeit beim verteilten Debugging, und die Telemetrie-API öffnet die Tür zu KI-gestützter Diagnostik.

Wenn du bereits Aspire nutzt, aktualisiere. Wenn nicht — das ist ein guter Grund, aspire.dev auszuprobieren.

Aspire | The .NET Blog

Private Endpoints, VNets, NSGs — Aspire übernimmt jetzt das Netzwerk

Die Bausteine

Beschreibung im AppHost

Warum das für echte Anwendungen wichtig ist

Fazit

Aspire 13.3: Kubernetes-Unterstützung, Browser-Logs und die Aspireify-Funktion

Aspireify: Agentengestütztes Onboarding

Erstklassiges Kubernetes- und AKS-Deployment

Browser-Logs im Dashboard

Strukturierte Befehlsergebnisse

Fazit

Aspire 13.2: Bun-Support, bessere Container und weniger Debug-Reibung

Bun ist jetzt erstklassig

Yarn wurde zuverlässiger

Container-Verbesserungen

Explizite Pull Policy

PostgreSQL 18+ funktioniert korrekt

Debugging-Verbesserungen

Fazit

Global Azure Spain 2026

Highlights der Agenda

Tickets

Azure Tour 2026

Hör auf, dein Terminal zu babysitzen: Aspires Detached Mode verändert den Workflow

Detached Mode: ein Befehl, Terminal zurück

Laufende Prozesse verwalten

Kombiniere es mit dem isolierten Modus

Warum das für Coding-Agents riesig ist

Fazit

.NET Aspire 13.2 Will der Beste Freund Deines KI-Agenten Sein

Das Problem ist real

Aspire als Agenten-Infrastruktur

Die Bowlingbahn-Bumper-Analogie

Erste Schritte

Zusammenfassung

Aspires Isolierter Modus Behebt den Port-Konflikt-Albtraum für Parallele Entwicklung

Die Lösung: --isolated

Reale Szenarien, in denen das glänzt

Wie es unter der Haube funktioniert

Wann man es verwenden sollte

Zusammenfassung

Aspire 13.2 liefert eine Docs-CLI — und dein KI-Agent kann sie auch nutzen

Das Problem, das hier wirklich gelöst wird

Drei Befehle, null Browser-Tabs

Alle Docs auflisten

Nach einem Thema suchen

Eine vollständige Seite lesen (oder nur einen Abschnitt)

Der KI-Agent-Aspekt

Praxisszenarien

Die Dokumentation ist immer aktuell

Zum Abschluss

Das Aspire 13.2 Dashboard hat jetzt eine Telemetrie-API — und das ändert alles

Telemetrie exportieren wie ein normaler Mensch

Die Telemetrie-API ist der echte Game Changer

GenAI-Telemetrie wird praktisch

Zusammenfassung

Die Lösung: `--isolated`