Cli | The .NET Blog

dotnet new WinUI: Windows-Apps erstellen ohne Visual Studio anzufassen

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

WinUI-Entwicklung erforderte früher Visual Studio. Das ändert sich: Microsoft hat Open-Source-Projekt- und Elementvorlagen für WinUI veröffentlicht, die mit dotnet new funktionieren und die Windows-App-Entwicklung in den Standard-CLI-Workflow bringen.

In drei Befehlen loslegen

# Vorlagen installieren
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates

# Eine NavigationView-App erstellen
dotnet new winui-navview -n MyApp

# Ausführen
cd MyApp
dotnet run

Kein Visual Studio, keine manuelle Projekteinrichtung. Die App läuft mit dotnet run.

Was enthalten ist

Leere Vorlage (dotnet new winui) — ein moderner Ausgangspunkt mit einer bereits konfigurierten Fluent-Titelleiste, aktualisiertem Standard-App-Symbol mit .ico-Asset und korrekten Hell-/Dunkel-Modus-Standardwerten. Besser als die alte leere Vorlage, bei der man die Grundlagen selbst konfigurieren musste.

NavigationView-Vorlage (dotnet new winui-navview) — das Master-Detail-Navigationsmuster, vollständig eingerichtet mit einer NavigationView, moderner Titelleiste und mehrseitiger Navigationsstruktur. Folgt der standardmäßigen Windows-App-Silhouette für navigationsbasierte Apps. Wenn Sie etwas mit Seitennavigation bauen, fangen Sie hier an.

Beide Vorlagen folgen den Windows-App-Silhouetten — moderne Fluent-Design-Muster für Layout, Navigation und visuelle Struktur — direkt aus der Box.

Warum das für Entwickler außerhalb von Visual Studio wichtig ist

WinUI-Entwickler, die VS Code, Rider oder Befehlszeilenwerkzeuge verwenden, wurden bisher benachteiligt. Die vorhandenen Visual Studio-Vorlagen waren außerhalb von VS nicht nutzbar — man musste die Projektstruktur manuell nachbilden und die Grundlagen selbst einrichten.

Diese Vorlagen sind Open Source (siehe WindowsAppSDK PR #6407), aus Community-Feedback entwickelt und jetzt verfügbar. Die Visual Studio-Unterstützung befindet sich in Arbeit — diese Vorlagen werden irgendwann auch dort funktionieren.

Für Teams, die ihr WinUI-Projekt-Setup automatisieren, in CI integrieren oder einfach einen anderen Editor als Visual Studio verwenden möchten, ist das eine bedeutsame Verbesserung.

Original-Post: Introducing dotnet new WinUI templates

Cosmos DB Shell Ist in der Öffentlichen Vorschau — Und Es Hat einen Integrierten MCP-Server

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

Wenn Sie jemals zwischen einem Portal-Tab, einem SDK-Beispiel und einem halbfertigen Skript hin- und herspringen mussten, nur um eine Cosmos DB-Frage zu beantworten, kennen Sie bereits die Reibung, die dieses Projekt zu beseitigen versucht.

Azure Cosmos DB Shell ist gerade in die öffentliche Vorschau gestartet. Es ist ein Open-Source-CLI mit bash-ähnlicher Syntax und — der Teil, der es interessant macht — einem integrierten MCP-Server.

Was Es von Anderen Datenbank-CLIs Unterscheidet

Das CLI selbst ist nützlich: vertraute Befehle, Skript-Unterstützung, CI/CD-Integration. Dieser Teil ist das Mindestmaß für ein entwicklerorientiertes Datenbank-Tool.

Der interessante Teil ist die MCP-Server-Integration. Jeder Befehl, den das CLI bereitstellt, wird als MCP-Tool verfügbar, das Ihre KI-Agenten aufrufen können. Es gibt keine benutzerdefinierte API-Schicht, keinen Integrationscode zu schreiben. Ihr Agent kann:

Datenbankhierarchien mit cd, ls, pwd navigieren
SQL-Abfragen mit query ausführen und strukturierte Ergebnisse zurückbekommen
Elemente mit create item, update, rm erstellen und ändern
Datenbanken und Container mit mkdb, mkcon, rmdb, rmcon verwalten
Den aktuellen Kontext mit endpoint, pwd inspizieren

Die wichtigste Verschiebung: Ihr Agent spricht nicht mit einer Cosmos DB-API — er spricht mit derselben Shell-Schnittstelle, die Sie verwenden. Die Befehle sind deterministisch, prüfbar und Open Source, sodass Sie genau sehen können, was passiert.

Die Open-Source-Grundlage Ist Wichtig

Dies ist kein verwalteter Black-Box-Dienst. Die Shell ist Open Source, was bedeutet:

Sicherheitsteams können die Implementierung prüfen
Plattformteams können sie forken und für ihre spezifischen Standards erweitern
Entwickler können Verbesserungen beitragen, die allen zugutekommen

Für Unternehmens-Teams, die KI-Tools einsetzen, ist “können wir genau sehen, wie es funktioniert” zunehmend keine optionale Anforderung. Open Source ist hier ein bedeutsames Unterscheidungsmerkmal.

Drei Szenarien, Die Einfacher Werden

Intelligente Datenanalyse — verbinden Sie einen Agenten mit der Shell, stellen Sie Fragen in natürlicher Sprache, erhalten Sie strukturierte Abfrageergebnisse. Der Agent übernimmt die Abfragekonstruktion; die Shell übernimmt die Ausführung.

Autonomes Datenmanagement — Workflows, die Daten in Cosmos DB erstellen, aktualisieren oder entfernen müssen, können dies über die MCP-Tools tun, ohne eine benutzerdefinierte Integration zu benötigen.

Echtzeit-Überwachung und Warnungen — ein Agent kann Container periodisch abfragen, Ergebnisse vergleichen und Anomalien über den passenden Benachrichtigungskanal melden.

Die MCP-Schnittstelle macht diese Szenarien mit jeder KI-Plattform, die MCP spricht, kombinierbar — nicht nur mit Microsofts Tools.

Erste Schritte

Die Shell ist in der öffentlichen Vorschau. Installieren Sie sie, konfigurieren Sie Ihre Cosmos DB-Verbindung und aktivieren Sie den MCP-Server. Von dort aus kann jeder MCP-kompatible Agent-Host die Tools entdecken und verwenden.

Originalbeitrag: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Windows App Dev CLI v0.3: F5 aus dem Terminal und UI-Automatisierung für Agenten

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

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

Die F5-Erfahrung von Visual Studio ist großartig. Aber VS nur zum Starten und Debuggen einer gepackten Windows-App öffnen zu müssen, ist zu viel — egal ob man in einer CI-Pipeline ist, einen automatisierten Workflow ausführt oder ein KI-Agent die Tests durchführt.

Windows App Development CLI v0.3 wurde veröffentlicht und adressiert das direkt mit zwei Hauptfunktionen: winapp run und winapp ui.

winapp run: F5 von überall

winapp run nimmt einen ungepackten App-Ordner und ein Manifest und erledigt alles, was VS beim Debug-Start tut: registriert ein Loose-Paket, startet die App und bewahrt den LocalState zwischen Re-Deploys.

# App bauen, dann als gepackte App starten
winapp run ./bin/Debug

Funktioniert für WinUI, WPF, WinForms, Console, Avalonia und mehr. Die Modi sind für Entwickler und automatisierte Workflows ausgelegt:

--detach: Startet und gibt die Kontrolle sofort an das Terminal zurück. Ideal für CI.
--unregister-on-exit: Räumt das registrierte Paket beim App-Schließen auf.
--debug-output: Erfasst OutputDebugString-Meldungen und Ausnahmen in Echtzeit. Mit --symbols werden PDBs vom Microsoft Symbol Server geladen.

Neues NuGet-Paket: dotnet run für gepackte Apps

Für .NET-Entwickler gibt es ein neues NuGet-Paket: Microsoft.Windows.SDK.BuildTools.WinApp. Nach der Installation handhabt dotnet run den gesamten Inner Loop: Build, Loose-Layout-Paket vorbereiten, bei Windows registrieren und starten — alles in einem Schritt.

# winapp init erledigt die Einrichtung
winapp init
# Oder direkt installieren
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

Funktioniert mit WinUI, WPF, WinForms, Console, Avalonia. Keine manuellen Schritte, nur dotnet run.

winapp ui: UI-Automatisierung aus der Kommandozeile

Das ist der Feature, der agentische Szenarien ermöglicht. winapp ui bietet vollständigen UI-Automatisierungszugriff auf jede laufende Windows-App — WPF, WinForms, Win32, Electron, WinUI3 — direkt aus dem Terminal.

Was möglich ist:

Alle Fenster der obersten Ebene auflisten
Den vollständigen UI-Automatisierungsbaum eines Fensters traversieren
Elemente nach Name, Typ oder Automatisierungs-ID suchen
Klicken, aufrufen und Werte setzen
Screenshots aufnehmen
Auf das Erscheinen von Elementen warten — ideal für Testsynchronisierung

winapp ui und winapp run kombiniert ergeben einen vollständigen Build → Start → Verifikation-Workflow aus dem Terminal. Ein Agent kann die App ausführen, den UI-Zustand prüfen, programmatisch interagieren und das Ergebnis validieren.

Weitere Neuerungen

winapp unregister: Entfernt ein sidegeladenes Dev-Paket nach dem Test.
winapp manifest add-alias: Fügt einen uap5:AppExecutionAlias hinzu, damit die App per Name aus dem Terminal gestartet werden kann.
Tab-Vervollständigung: Ein Befehl für die vollständige PowerShell-Vervollständigung.
Package.appxmanifest als Standard: winapp init erzeugt jetzt Package.appxmanifest (VS-Konvention) statt appxmanifest.xml.

Installation

winget install Microsoft.WinAppCli
# oder
npm install -g @microsoft/winappcli

Die CLI ist in Public Preview. Das GitHub-Repository enthält vollständige Dokumentation, und die ursprüngliche Ankündigung hat alle Details.

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.

azd update — Ein Befehl für alle deine Paketmanager

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

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

Kennst du diese Meldung „Eine neue Version von azd ist verfügbar", die alle paar Wochen auftaucht? Die, die du wegklickst, weil du dich nicht mehr erinnerst, ob du azd über winget, Homebrew oder dieses curl-Skript installiert hast, das du vor sechs Monaten ausgeführt hast? Ja, das ist jetzt endlich gelöst.

Microsoft hat azd update veröffentlicht — ein einziger Befehl, der die Azure Developer CLI auf die neueste Version aktualisiert, unabhängig davon, wie du sie ursprünglich installiert hast. Windows, macOS, Linux — egal. Ein Befehl.

So funktioniert’s

azd update

Das war’s. Wenn du frühen Zugang zu neuen Features möchtest, kannst du auf den täglichen Insiders-Build wechseln:

azd update --channel daily
azd update --channel stable

Der Befehl erkennt deine aktuelle Installationsmethode und nutzt im Hintergrund den passenden Update-Mechanismus. Kein „Moment, habe ich auf diesem Rechner winget oder choco benutzt?" mehr.

Der kleine Haken

azd update ist ab Version 1.23.x verfügbar. Wenn du eine ältere Version hast, musst du ein letztes manuelles Update mit deiner ursprünglichen Installationsmethode durchführen. Danach übernimmt azd update alles Weitere.

Prüfe deine aktuelle Version mit azd version. Falls du eine Neuinstallation brauchst, hilft dir die Installationsdokumentation weiter.

Warum das wichtig ist

Es ist eine kleine Verbesserung der Lebensqualität, aber für diejenigen von uns, die azd täglich zum Deployen von KI-Agenten und Aspire-Apps auf Azure nutzen, bedeutet auf dem neuesten Stand zu sein weniger „dieser Bug war schon in der letzten Version behoben"-Momente. Eine Sache weniger, über die man nachdenken muss.

Lies die vollständige Ankündigung und Jon Gallants tiefergehende Analyse für mehr Kontext.

.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.

Cli | The .NET Blog

dotnet new WinUI: Windows-Apps erstellen ohne Visual Studio anzufassen

In drei Befehlen loslegen

Was enthalten ist

Warum das für Entwickler außerhalb von Visual Studio wichtig ist

Cosmos DB Shell Ist in der Öffentlichen Vorschau — Und Es Hat einen Integrierten MCP-Server

Was Es von Anderen Datenbank-CLIs Unterscheidet

Die Open-Source-Grundlage Ist Wichtig

Drei Szenarien, Die Einfacher Werden

Erste Schritte

Windows App Dev CLI v0.3: F5 aus dem Terminal und UI-Automatisierung für Agenten

winapp run: F5 von überall

Neues NuGet-Paket: dotnet run für gepackte Apps

winapp ui: UI-Automatisierung aus der Kommandozeile

Weitere Neuerungen

Installation

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

azd update — Ein Befehl für alle deine Paketmanager

So funktioniert’s

Der kleine Haken

Warum das wichtig ist

.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

Die Lösung: `--isolated`