Developer Tools | The .NET Blog

VS Code 1.119: OpenTelemetry für Agent-Sitzungen, Browser-Integration und Sicherheit

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

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

VS Code 1.119 wurde am 6. Mai 2026 veröffentlicht (mit einem 1.119.1-Sicherheits-Patch kurz danach). Das Release konzentriert sich auf Agent-Observability, Browser-Interaktion und die Reduzierung von Unterbrechungen.

OpenTelemetry-Tracing für Agent-Sitzungen

Dies ist das herausragende Feature für alle, die Agents in der Produktion betreiben oder agentische Workflows debuggen. Aktivieren Sie es mit zwei Einstellungen:

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

Traces folgen den semantischen GenAI-Konventionen. Jede Agent-Anfrage erzeugt einen invoke_agent-Root-Span mit verschachtelten Child-Spans: chat, execute_tool und execute_hook. Token-Nutzung wird pro Anfrage gemeldet — einschließlich Cache-Lese- und Cache-Erstellungszählungen.

Funktioniert mit dem lokalen Agent, dem Copilot CLI Hintergrund-Agent und dem Claude-Agent. Jedes OTLP-kompatible Backend akzeptiert die Traces — das Aspire Dashboard Standalone eignet sich gut für die lokale Entwicklung.

Agents können jetzt auf Browser-Tabs zugreifen

Agents können den Zugriff auf Ihre integrierten Browser-Tabs anfordern — aber nicht automatisch. Sie müssen einen Tab explizit über den Kontext-Picker, Drag-and-Drop oder vorgeschlagenen Kontext freigeben. Im Browser gibt es eine Freigabe-Schaltfläche zum Widerrufen des Zugriffs. Wenn ein Agent versucht, einen neuen Tab auf derselben Domain wie ein bereits offener (nicht freigegebener) Tab zu öffnen, fordert VS Code Sie auf, den vorhandenen Tab wiederzuverwenden.

Optimierte Token-Nutzung

Ein experimentelles leichtgewichtiges Modell übernimmt jetzt die Verwaltung von Agent-Aufgabenlisten und hält diese Verwaltungsarbeit vom teureren Primärmodell fern. Reduziert den Token-Verbrauch für Aufgaben, die keine volle Reasoning-Kapazität benötigen.

Vertrauen und Sicherheit

Weniger Unterbrechungen: VS Code 1.119 reduziert Aufforderungen für Netzwerkzugriffsanfragen und Schreibvorgänge in temporäre Ordner durch Agents. Der 1.119.1-Patch behebt spezifische Sicherheitsprobleme — ein Update lohnt sich, falls noch nicht geschehen.

Schneller Wechsel zur Markdown-Vorschau

Klein aber nützlich: Sie können jetzt schnell den aktuellen Editor zur Markdown-Vorschau wechseln, ohne zu navigieren.

VS Code Agents (Insiders-Vorschau)

Die neu gestaltete Agent-Sitzungs-UI — neuer Repository-Picker (lokal/Repos/remote), Verbesserungen bei Unter-Sitzungen, Web- und Mobile-Polishing, Fortschrittsanimationen — ist in Insiders unter insiders.vscode.dev/agents verfügbar.

Vollständiges Changelog: code.visualstudio.com/updates/v1_119.

Azure Data Studio wird eingestellt: Azure SQL-Workflows zu VS Code migrieren

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

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

Azure Data Studio wurde am 6. Februar 2025 eingestellt, der Support endet am 28. Februar 2026 — der empfohlene Ersatz ist VS Code mit der MSSQL-Erweiterung.

Was zu installieren ist

Drei Dinge für den Einstieg:

MSSQL-Erweiterung — suche nach „SQL Server (mssql)" im VS Code Marketplace
SQL Database Projects-Erweiterung — Schema als Code, Build-Validierung, geführte Veröffentlichung
.NET 8 SDK — vom Build-System benötigt; fehlendes SDK ist das häufigste Problem beim ersten Start

ADS-Verbindungen und Einstellungen migrieren

Die MSSQL-Erweiterung enthält das ADS Migration Toolkit, das die einmalige Migration in einem geführten Ablauf übernimmt: gespeicherte Verbindungen, Verbindungsgruppen, Einstellungen und Tastenkürzel werden automatisch importiert.

F5-Muskelgedächtnis wiederherstellen

ADS-Nutzer verlassen sich auf F5 zum Ausführen von Abfragen. Installiere die Erweiterung MSSQL Database Management Keymap, um ADS-Tastenkürzel inklusive F5 zurückzubekommen.

SQL Database Projects: Schema als Code

Rechtsklick auf ein Projekt → Veröffentlichen → Ziel konfigurieren → generierten T-SQL-Script prüfen → deployen. Die Script-Vorschau vor dem Deployment ist das zentrale Sicherheitsmerkmal. Elementvorlagen erzeugen Stubs für Tabellen, gespeicherte Prozeduren und Views — derselbe Workflow wie bei SSDT.

Häufiges Problem: eine Zielplattform-Inkompatibilität in der .sqlproj-Datei verursacht Build-Fehler, wenn das Projekt gegen eine andere SQL Server-Version erstellt wurde.

Schema Compare und Schema Designer

Die Erweiterung enthält außerdem Schema Compare (Unterschiede zwischen Projekt und bereitgestellter Datenbank) und Schema Designer (visuelle Schema-Bearbeitung ohne manuelles DDL-Schreiben).

Microsoft Fabric-Entwickler

Die Einrichtung ist identisch, aber starte zunächst im Fabric-Portal und verbinde die Datenbank zuerst mit Git, bevor du sie in VS Code öffnest. Microsoft hat einen dedizierten Leitfaden: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Fazit

Die Migration ist ein einmaliger geführter Ablauf, kein manueller Neuaufbau. Installiere die drei Tools, führe das ADS Migration Toolkit aus, stelle die Tastenkürzel wieder her — und du bist in unter 10 Minuten wieder einsatzbereit.

Den vollständigen Artikel findest du mit Schritt-für-Schritt-Screenshots und der Fabric-spezifischen Anleitung.

Der Azure MCP Server ist jetzt ein .mcpb — Ohne Runtime Installieren

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

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

Weißt du, was an der Einrichtung von MCP-Servern lästig war? Du brauchtest eine Runtime. Node.js für die npm-Version, Python für pip/uvx, .NET SDK für die dotnet-Variante.

Der Azure MCP Server hat das gerade geändert. Er ist jetzt als .mcpb — ein MCP Bundle — verfügbar, und die Einrichtung ist Drag-and-Drop.

Was ist ein MCP Bundle?

Denk daran wie an eine VS Code-Erweiterung (.vsix) oder eine Browser-Erweiterung (.crx), aber für MCP-Server. Eine .mcpb-Datei ist ein eigenständiges ZIP-Archiv mit dem Server-Binary und allen Abhängigkeiten.

Installation

1. Bundle für deine Plattform herunterladen

Gehe auf die GitHub Releases-Seite und lade die .mcpb-Datei für dein OS und deine Architektur herunter. Stelle sicher, dass du die richtige wählst — osx-arm64 für Apple Silicon, win-x64 für Windows, usw.

2. In Claude Desktop installieren

Am einfachsten: Ziehe die .mcpb-Datei in das Claude Desktop-Fenster während du auf der Erweiterungsseite bist (☰ → Datei → Einstellungen → Erweiterungen). Serverdetails überprüfen, Installieren klicken, bestätigen. Fertig.

3. Bei Azure authentifizieren

az login

Das war’s. Der Azure MCP Server nutzt deine vorhandenen Azure-Anmeldeinformationen.

Was du damit machen kannst

Über 100 Azure-Service-Tools direkt von deinem KI-Client:

Cosmos DB, Storage, Key Vault, App Service, Foundry abfragen und verwalten
az CLI-Befehle für beliebige Aufgaben generieren
Bicep- und Terraform-Vorlagen erstellen

Erste Schritte

Download: GitHub Releases
Repository: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Siehe den vollständigen Beitrag.

VS Code 1.118: Copilot CLI bekommt Sitzungsnamen, Modell-Badges und TypeScript 7.0 Nightly

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

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

Visual Studio Code 1.118 ist ein kleineres, fokussiertes Release — hauptsächlich Copilot CLI-Verfeinerungen — aber ein paar Dinge sind es wert, notiert zu werden.

Copilot CLI: Sitzungen bekommen echte Namen

Die Sitzungstitel-APIs des Copilot CLI SDK werden jetzt als Quelle der Wahrheit für Sitzungsnamen verwendet. Statt automatisch generierter Labels zeigen Sitzungen jetzt den echten Namen aus dem SDK.

Schneller zwischen Sitzungen wechseln

Die Agents-App hat jetzt Ctrl+1, Ctrl+2, usw. für den schnellen Wechsel zwischen Sitzungen belegt. Für Entwickler, die mehrere Copilot CLI-Sitzungen parallel betreiben, spart das viele Mausklicks.

Modell-Badges im Chat

Copilot CLI-Antworten im Chat-Panel zeigen jetzt ein Modell-Badge — auf einen Blick erkennbar, welches Modell jede Anfrage bearbeitet hat.

Automatische Modellauswahl in Copilot CLI

Die automatische Modellauswahl — zuvor in anderen Teilen von Copilot verfügbar — funktioniert jetzt auch im Copilot CLI-Agenten.

TypeScript 7.0 Nightly Opt-in

Du kannst jetzt direkt über die VS Code-Einstellungen die TypeScript 7.0 Nightlies testen. TypeScript 7.0 ist ein bedeutendes Release (die Beta erschien vor einigen Tagen).

Sieh dir die vollständigen Release-Notes an.

azd-Hooks in Python, TypeScript und .NET: Schluss mit Shell-Skripten

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

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

Wer schon einmal ein vollständig in .NET geschriebenes Projekt hatte und trotzdem Bash-Skripte für azd-Hooks schreiben musste, kennt den Schmerz. Warum in Shell-Syntax wechseln für einen Pre-Provisioning-Schritt, wenn der Rest des Projekts C# ist?

Diese Frustration hat jetzt eine offizielle Lösung. Die Azure Developer CLI hat Multi-Sprachen-Unterstützung für Hooks eingeführt, und es ist genauso gut wie es klingt.

Was sind Hooks?

Hooks sind Skripte, die an wichtigen Punkten im azd-Lebenszyklus ausgeführt werden — vor dem Provisioning, nach dem Deployment und mehr. Sie werden in azure.yaml definiert und ermöglichen die Injektion von benutzerdefinierter Logik ohne Änderungen an der CLI.

Bisher wurden nur Bash und PowerShell unterstützt. Jetzt kann man Python, JavaScript, TypeScript oder .NET verwenden — und azd erledigt den Rest automatisch.

Wie die Erkennung funktioniert

Man verweist den Hook auf eine Datei, und azd leitet die Sprache aus der Dateiendung ab:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Keine zusätzliche Konfiguration. Bei mehrdeutigen Endungen kann man kind: python (oder die entsprechende Sprache) explizit angeben.

Sprachspezifische Details

Python

Eine requirements.txt oder pyproject.toml neben dem Skript ablegen (oder in einem übergeordneten Verzeichnis). azd erstellt automatisch eine virtuelle Umgebung, installiert Abhängigkeiten und führt das Skript aus.

JavaScript und TypeScript

Dasselbe Muster — eine package.json in der Nähe des Skripts, und azd führt zuerst npm install aus. Für TypeScript wird npx tsx verwendet, ohne Kompilierungsschritt und ohne tsconfig.json.

.NET

Zwei Modi verfügbar:

Projektmodus: Liegt eine .csproj neben dem Skript, führt azd automatisch dotnet restore und dotnet build aus.
Single-File-Modus: Ab .NET 10+ können eigenständige .cs-Dateien direkt via dotnet run script.cs ausgeführt werden. Kein Projektdatei erforderlich.

Executor-spezifische Konfiguration

Jede Sprache unterstützt einen optionalen config-Block:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Warum das für .NET-Entwickler wichtig ist

Hooks waren der letzte Ort in einem azd-basierten Projekt, der einen Sprachwechsel erzwang. Jetzt kann die gesamte Deployment-Pipeline — App-Code, Infrastrukturskripte und Lifecycle-Hooks — in einer einzigen Sprache leben. Bestehende .NET-Utilities lassen sich in Hooks wiederverwenden, gemeinsame Bibliotheken referenzieren, und Shell-Skript-Pflege entfällt.

Fazit

Einer dieser Änderungen, die klein klingen, aber täglich Reibung aus dem azd-Workflow nehmen. Multi-Sprachen-Hook-Unterstützung ist jetzt verfügbar — alle Details im offiziellen Post.

Foundry Toolboxes: Ein einziger Endpunkt für alle Agent-Tools

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

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

Hier ist ein Problem, das banal klingt, bis man es selbst erlebt: Die Organisation baut mehrere KI-Agenten, jeder braucht Tools, und jedes Team verkabelt sie von Grund auf neu. Dieselbe Web-Search-Integration, dieselbe Azure AI Search-Konfiguration, dieselbe GitHub-MCP-Server-Verbindung — aber in einem anderen Repository, von einem anderen Team, mit anderen Credentials und ohne gemeinsame Governance.

Microsoft Foundry hat soeben Toolboxes in der Public Preview veröffentlicht — eine direkte Antwort auf dieses Problem.

Was ist eine Toolbox?

Eine Toolbox ist ein benanntes, wiederverwendbares Tool-Bundle, das man einmal in Foundry definiert und über einen einzigen MCP-kompatiblen Endpunkt bereitstellt. Jede Agent-Runtime, die MCP spricht, kann sie konsumieren — kein Lock-in bei Foundry Agents.

Das Versprechen ist einfach: build once, consume anywhere. Tools definieren, Authentifizierung zentral konfigurieren (OAuth passthrough, Entra Managed Identity), Endpunkt veröffentlichen. Jeder Agent, der diese Tools braucht, verbindet sich einmal und bekommt sie alle.

Die vier Säulen (zwei davon heute verfügbar)

Säule	Status	Was sie tut
Discover	Demnächst	Genehmigte Tools finden ohne manuelle Suche
Build	Heute verfügbar	Tools in ein wiederverwendbares Bundle kuratieren
Consume	Heute verfügbar	Ein MCP-Endpunkt stellt alle Tools bereit
Govern	Demnächst	Zentrale Auth + Observability für alle Tool-Calls

Praktisches Beispiel

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Dokumentation durchsuchen und auf GitHub-Issues reagieren.",
 tools=[
 {"type": "web_search", "description": "Öffentliche Dokumentation suchen"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Nach der Veröffentlichung liefert Foundry einen einheitlichen Endpunkt. Eine Verbindung, alle Tools.

Kein Lock-in bei Foundry Agents

Toolboxes werden in Foundry erstellt und verwaltet, aber die Konsumfläche ist das offene MCP-Protokoll. Sie können von Custom Agents mit Microsoft Agent Framework oder LangGraph, GitHub Copilot und anderen MCP-fähigen IDEs sowie jeder anderen MCP-Runtime genutzt werden.

Warum das jetzt wichtig ist

Die Multi-Agenten-Welle kommt in der Produktion an. Jeder neue Agent ist eine neue Fläche für duplizierte Konfiguration, veraltete Credentials und inkonsistentes Verhalten. Die Build + Consume-Grundlage reicht aus, um mit der Zentralisierung zu beginnen. Wenn die Govern-Säule kommt, hat man eine vollständig beobachtbare, zentral gesteuerte Tool-Schicht für die gesamte Agent-Flotte.

Fazit

Das ist noch früh — Public Preview, Python SDK zuerst, mit Discover und Govern noch ausstehend. Aber das Modell ist solide und das MCP-native Design bedeutet, dass es mit den Tools funktioniert, die man bereits aufbaut. Details im offiziellen Announcement.

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.

VS Code 1.117: Agents Bekommen Eigene Git-Branches und Ich Bin Voll Dabei

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

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

Die Grenze zwischen „KI-Assistent" und „KI-Teamkollege" wird immer dünner. VS Code 1.117 ist gerade erschienen und die vollständigen Release Notes sind vollgepackt, aber die Geschichte ist klar: Agents werden zu erstklassigen Bürgern in deinem Entwicklungs-Workflow.

Hier ist, was wirklich zählt.

Autopilot-Modus merkt sich endlich deine Einstellung

Bisher musstest du Autopilot bei jeder neuen Session neu aktivieren. Nervig. Jetzt bleibt dein Berechtigungsmodus über Sessions hinweg bestehen, und du kannst den Standard konfigurieren.

Der Agent Host unterstützt drei Session-Konfigurationen:

Default — Tools fragen vor der Ausführung nach Bestätigung
Bypass — genehmigt alles automatisch
Autopilot — vollständig autonom, beantwortet eigene Fragen und macht weiter

Wenn du ein neues .NET-Projekt mit Migrationen, Docker und CI aufbaust — stell es einmal auf Autopilot und vergiss es. Diese Einstellung bleibt.

Worktree- und Git-Isolation für Agent-Sessions

Das ist der große Wurf. Agent-Sessions unterstützen jetzt volle Worktree- und Git-Isolation. Das bedeutet: Wenn ein Agent an einer Aufgabe arbeitet, bekommt er seinen eigenen Branch und sein eigenes Arbeitsverzeichnis. Dein Hauptbranch bleibt unangetastet.

Noch besser — Copilot CLI generiert aussagekräftige Branch-Namen für diese Worktree-Sessions. Kein agent-session-abc123 mehr. Du bekommst etwas, das tatsächlich beschreibt, was der Agent tut.

Für .NET-Entwickler, die mehrere Feature-Branches verwalten oder Bugs fixen, während eine lange Scaffolding-Aufgabe läuft, ist das ein Game Changer. Du kannst einen Agent deine API-Controller in einem Worktree aufbauen lassen, während du ein Problem in der Service-Schicht in einem anderen debuggst. Keine Konflikte. Kein Stashing. Kein Chaos.

Subagents und Agent-Teams

Das Agent Host Protocol unterstützt jetzt Subagents. Ein Agent kann andere Agents starten, um Teile einer Aufgabe zu übernehmen. Stell dir das als Delegieren vor — dein Haupt-Agent koordiniert, und spezialisierte Agents kümmern sich um die einzelnen Teile.

Das ist noch früh, aber das Potenzial für .NET-Workflows ist offensichtlich. Stell dir vor, ein Agent kümmert sich um deine EF Core-Migrationen, während ein anderer deine Integrationstests einrichtet. Wir sind noch nicht ganz da, aber dass der Protokoll-Support jetzt landet, bedeutet, dass die Tools schnell folgen werden.

Terminal-Output wird automatisch mitgeliefert, wenn Agents Input senden

Klein aber bedeutsam. Wenn ein Agent Input an das Terminal sendet, wird der Terminal-Output jetzt automatisch in den Kontext einbezogen. Vorher musste der Agent eine extra Runde drehen, nur um zu lesen, was passiert ist.

Wenn du jemals einem Agent zugesehen hast, wie er dotnet build ausführt, scheitert und dann noch einen Roundtrip braucht, nur um den Fehler zu sehen — diese Reibung ist weg. Er sieht den Output sofort und reagiert.

Die Agents-App auf macOS aktualisiert sich selbst

Die eigenständige Agents-App auf macOS aktualisiert sich jetzt selbst. Kein manuelles Herunterladen neuer Versionen mehr. Sie bleibt einfach aktuell.

Die kleineren Dinge, die es wert sind zu wissen

package.json-Hovers zeigen jetzt sowohl die installierte Version als auch die neueste verfügbare. Nützlich, wenn du npm-Tooling neben deinen .NET-Projekten verwaltest.
Bilder in JSDoc-Kommentaren werden in Hovers und Completions korrekt gerendert.
Copilot CLI-Sessions zeigen jetzt an, ob sie von VS Code oder extern erstellt wurden — praktisch, wenn du zwischen Terminals springst.
Copilot CLI, Claude Code und Gemini CLI werden als Shell-Typen erkannt. Der Editor weiß, was du ausführst.

Das Fazit

VS Code 1.117 ist kein auffälliger Feature-Dump. Es ist Infrastruktur. Worktree-Isolation, persistente Berechtigungen, Subagent-Protokolle — das sind die Bausteine für einen Workflow, in dem Agents echte, parallele Aufgaben erledigen, ohne deinen Code zu beeinträchtigen.

Wenn du mit .NET baust und dich noch nicht auf den agentischen Workflow eingelassen hast, ehrlich gesagt, jetzt ist der richtige Zeitpunkt.

Docker Sandbox lässt Copilot-Agenten euren Code refactoren — ohne Risiko für eure Maschine

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

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

Wer Copilots Agent-Modus für mehr als kleine Änderungen genutzt hat, kennt den Schmerz. Jeder Dateischreibvorgang, jeder Terminal-Befehl — wieder eine Berechtigungsabfrage. Jetzt stellt euch das mal bei 50 Projekten vor. Macht keinen Spaß.

Das Azure-Team hat gerade einen Beitrag über Docker Sandbox für GitHub Copilot-Agenten veröffentlicht, und ehrlich gesagt ist das eine der praktischsten Verbesserungen für agentisches Tooling, die ich gesehen habe. Es nutzt MicroVMs, um Copilot eine vollständig isolierte Umgebung zu geben, in der er frei arbeiten kann — Pakete installieren, Builds ausführen, Tests laufen lassen — ohne euer Host-System zu berühren.

Was Docker Sandbox tatsächlich bietet

Die Kernidee ist simpel: Eine leichtgewichtige MicroVM mit einer vollständigen Linux-Umgebung hochfahren, euren Workspace hineinsynchronisieren und den Copilot-Agenten frei darin arbeiten lassen. Wenn er fertig ist, werden die Änderungen zurücksynchronisiert.

Das macht es zu mehr als nur “Sachen in einem Container ausführen”:

Bidirektionale Workspace-Synchronisation, die absolute Pfade beibehält. Eure Projektstruktur sieht innerhalb der Sandbox identisch aus. Keine pfadbedingten Build-Fehler.
Privater Docker-Daemon innerhalb der MicroVM. Der Agent kann Container bauen und ausführen, ohne jemals den Docker-Socket eures Hosts zu mounten. Das ist ein großer Sicherheitsgewinn.
HTTP/HTTPS-Filterproxys, die kontrollieren, was der Agent im Netzwerk erreichen kann. Ihr entscheidet, welche Registries und Endpoints erlaubt sind. Supply-Chain-Angriffe durch ein fragwürdiges npm install in der Sandbox? Geblockt.
YOLO-Modus — ja, so nennen sie das wirklich. Der Agent läuft ohne Berechtigungsabfragen, weil er buchstäblich euren Host nicht beschädigen kann. Jede destruktive Aktion ist eingedämmt.

Warum .NET-Entwickler aufhorchen sollten

Denkt an die Modernisierungsarbeit, vor der so viele Teams gerade stehen. Ihr habt eine .NET-Framework-Solution mit 30 Projekten und müsst auf .NET 9 umsteigen. Das sind hunderte Dateiänderungen — Projektdateien, Namespace-Updates, API-Ersetzungen, NuGet-Migrationen.

Mit Docker Sandbox könnt ihr einen Copilot-Agenten auf ein Projekt ansetzen, ihn innerhalb der MicroVM frei refactoren lassen, dotnet build und dotnet test zur Validierung ausführen und nur die Änderungen übernehmen, die tatsächlich funktionieren. Kein Risiko, dass er versehentlich eure lokale Entwicklungsumgebung zerschießt, während er experimentiert.

Der Beitrag beschreibt auch den Einsatz einer Flotte paralleler Agenten — jeder in seiner eigenen Sandbox — die gleichzeitig verschiedene Projekte bearbeiten. Für große .NET-Solutions oder Microservice-Architekturen ist das eine massive Zeitersparnis. Ein Agent pro Service, alle isoliert laufend, alle unabhängig validiert.

Der Sicherheitsaspekt zählt

Hier ist der Punkt, den die meisten übersehen: Wenn ihr einem KI-Agenten erlaubt, beliebige Befehle auszuführen, vertraut ihr ihm eure gesamte Maschine an. Docker Sandbox dreht dieses Modell um. Der Agent bekommt volle Autonomie in einer Wegwerfumgebung. Der Netzwerk-Proxy stellt sicher, dass er nur von genehmigten Quellen ziehen kann. Euer Host-Dateisystem, Docker-Daemon und eure Credentials bleiben unangetastet.

Für Teams mit Compliance-Anforderungen — und das sind die meisten .NET-Unternehmen — ist das der Unterschied zwischen “Wir können agentische KI nicht nutzen” und “Wir können sie sicher einsetzen.”

Fazit

Docker Sandbox löst die fundamentale Spannung des agentischen Programmierens: Agenten brauchen Freiheit, um nützlich zu sein, aber Freiheit auf eurer Host-Maschine ist gefährlich. MicroVMs geben euch beides. Wenn ihr großangelegtes .NET-Refactoring oder eine Modernisierung plant, lohnt es sich, das jetzt einzurichten. Die Kombination aus Copilots Code-Intelligenz mit einer sicheren Ausführungsumgebung ist genau das, worauf Produktionsteams gewartet haben.

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.

Azure MCP Tools sind jetzt in Visual Studio 2022 integriert — Keine Erweiterung erforderlich

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

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

Wenn du die Azure MCP Tools in Visual Studio über die separate Erweiterung benutzt hast, kennst du das Spiel — VSIX installieren, neustarten, hoffen dass nichts kaputtgeht, Versionskonflikte managen. Diese Reibung ist vorbei.

Yun Jung Choi hat angekündigt, dass Azure MCP Tools jetzt direkt als Teil der Azure-Entwicklungsworkload in Visual Studio 2022 ausgeliefert werden. Keine Erweiterung. Kein VSIX. Kein Neustart-Tanz.

Was das konkret bedeutet

Ab Visual Studio 2022 Version 17.14.30 ist der Azure MCP Server in der Azure-Entwicklungsworkload enthalten. Wenn du diese Workload bereits installiert hast, musst du ihn nur in GitHub Copilot Chat aktivieren und fertig.

Über 230 Tools für 45 Azure-Dienste — direkt aus dem Chat-Fenster zugänglich. Storage Accounts auflisten, eine ASP.NET Core App deployen, App Service Probleme diagnostizieren, Log Analytics abfragen — alles ohne einen Browser-Tab zu öffnen.

Warum das wichtiger ist als es klingt

Die Sache mit Entwickler-Tooling ist: Jeder zusätzliche Schritt ist Reibung, und Reibung tötet die Akzeptanz. MCP als separate Erweiterung bedeutete Versionskonflikte, Installationsfehler und eine weitere Sache, die aktuell gehalten werden musste. Die Integration in die Workload bedeutet:

Ein einziger Update-Pfad über den Visual Studio Installer
Kein Versionsabweichung zwischen der Erweiterung und der IDE
Immer aktuell — der MCP Server wird mit den regulären VS-Releases aktualisiert

Für Teams, die auf Azure standardisieren, ist das ein großer Gewinn. Du installierst die Workload einmal, aktivierst die Tools, und sie sind in jeder Sitzung verfügbar.

Was du damit machen kannst

Die Tools decken den gesamten Entwicklungslebenszyklus über Copilot Chat ab:

Lernen — frage nach Azure-Diensten, Best Practices, Architekturmustern
Entwerfen & Entwickeln — erhalte Service-Empfehlungen, konfiguriere App-Code
Deployen — provisioniere Ressourcen und deploye direkt aus der IDE
Fehlerbehebung — frage Logs ab, prüfe den Ressourcenzustand, diagnostiziere Produktionsprobleme

Ein schnelles Beispiel — tippe das in Copilot Chat:

List my storage accounts in my current subscription.

Copilot ruft die Azure MCP Tools im Hintergrund auf, fragt deine Subscriptions ab und liefert eine formatierte Liste mit Namen, Standorten und SKUs. Kein Portal nötig.

So aktivierst du es

Update auf Visual Studio 2022 17.14.30 oder höher
Stelle sicher, dass die Azure development Workload installiert ist
Öffne GitHub Copilot Chat
Klicke auf den Select tools Button (das Schraubenschlüssel-Symbol)
Schalte Azure MCP Server ein

Das war’s. Es bleibt über Sitzungen hinweg aktiviert.

Ein Hinweis

Die Tools sind standardmäßig deaktiviert — du musst sie manuell einschalten. Und VS 2026-spezifische Tools sind in VS 2022 nicht verfügbar. Die Verfügbarkeit der Tools hängt auch von deinen Azure-Subscription-Berechtigungen ab, genau wie im Portal.

Das große Bild

Das ist Teil eines klaren Trends: MCP wird zum Standard, um Cloud-Tools in Entwickler-IDEs verfügbar zu machen. Wir haben bereits das stabile Release von Azure MCP Server 2.0 und MCP-Integrationen in VS Code und anderen Editoren gesehen. Die Integration in Visual Studios Workload-System ist die natürliche Weiterentwicklung.

Für uns .NET-Entwickler, die in Visual Studio leben, entfällt damit ein weiterer Grund, zum Azure Portal zu wechseln. Und ehrlich gesagt, je weniger Tab-Wechsel, desto besser.

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.

Die Visual Studio Floating-Windows-Einstellung, die Du Nicht Kanntest (Aber Kennen Solltest)

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

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

Wenn ihr mehrere Monitore mit Visual Studio verwendet (und ehrlich gesagt, wer macht das heutzutage nicht?), habt ihr wahrscheinlich schon die Frustration erlebt: Schwebende Toolfenster verschwinden, wenn ihr das Haupt-IDE minimiert, sie bleiben immer über allem anderen, und sie tauchen nicht als separate Taskleisten-Buttons auf. Das funktioniert für manche Workflows, aber für Multi-Monitor-Setups ist es nervig.

Mads Kristensen vom Visual Studio Team teilte eine kaum bekannte Einstellung, die komplett verändert, wie sich schwebende Fenster verhalten. Ein Dropdown. Das war’s.

Die Einstellung

Tools > Options > Environment > Windows > Floating Windows

Das Dropdown “These floating windows are owned by the main window” hat drei Optionen:

None — volle Unabhängigkeit. Jedes schwebende Fenster bekommt seinen eigenen Taskleisten-Eintrag und verhält sich wie ein normales Windows-Fenster.
Tool Windows (Standard) — Dokumente schweben frei, Toolfenster bleiben an die IDE gebunden.
Documents and Tool Windows — klassisches Visual Studio-Verhalten, alles an das Hauptfenster gebunden.

Warum “None” der richtige Weg für Multi-Monitor-Setups ist

Stellt es auf None und plötzlich verhalten sich alle eure schwebenden Tool- und Dokumentfenster wie echte Windows-Anwendungen. Sie erscheinen in der Taskleiste, bleiben sichtbar wenn ihr das Visual Studio-Hauptfenster minimiert, und hören auf, sich vor alles andere zu drängen.

Kombiniert das mit PowerToys FancyZones und es ist ein Game Changer. Erstellt benutzerdefinierte Layouts über eure Monitore, dockt euren Solution Explorer in eine Zone, Debugger in eine andere, und Code-Dateien wohin ihr wollt. Alles bleibt an Ort und Stelle, alles ist unabhängig erreichbar, und euer Arbeitsplatz fühlt sich organisiert an statt chaotisch.

Schnelle Empfehlungen

Multi-Monitor-Poweruser: Auf None setzen, mit FancyZones kombinieren
Gelegentliche Floater: Tool Windows (Standard) ist ein guter Mittelweg
Traditioneller Workflow: Documents and Tool Windows hält alles klassisch

Profi-Tipp: Ctrl + Doppelklick auf die Titelleiste eines beliebigen Toolfensters, um es sofort zu lösen oder anzudocken. Kein Neustart nötig nach dem Ändern der Einstellung.

Fazit

Es ist eine dieser “Ich kann nicht glauben, dass ich das nicht wusste”-Einstellungen. Wenn euch schwebende Fenster in Visual Studio jemals genervt haben, geht das jetzt sofort ändern.

Lest den vollständigen Post für Details und Screenshots.

VS Code 1.116 — Agents App Bekommt Tastaturnavigation und Dateikontext-Vervollständigungen

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

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

VS Code 1.116 ist das April 2026-Release, und obwohl es leichter ausfällt als einige neuere Updates, sind die Änderungen fokussiert und bedeutsam — besonders wenn ihr die Agents App täglich nutzt.

Hier ist, was gelandet ist, basierend auf den offiziellen Release Notes.

Verbesserungen der Agents App

Die Agents App reift weiter mit Usability-Verfeinerungen, die im täglichen Workflow einen echten Unterschied machen:

Dedizierte Tastenkürzel — ihr könnt jetzt die Changes-Ansicht, den Dateibaum innerhalb von Changes und die Chat-Personalisierungsansicht mit dedizierten Befehlen und Tastenkürzeln fokussieren. Wenn ihr bisher in der Agents App herumgeklickt habt, bringt das vollständig tastaturgesteuerte Workflows.

Barrierefreiheits-Hilfedialog — das Drücken von Alt+F1 im Chat-Eingabefeld öffnet jetzt einen Barrierefreiheits-Hilfedialog, der verfügbare Befehle und Tastenkürzel anzeigt. Screenreader-Nutzer können auch die Ausführlichkeit der Ansagen steuern. Gute Barrierefreiheit nützt allen.

Dateikontext-Vervollständigungen — tippt # im Agents App Chat, um Dateikontext-Vervollständigungen für euren aktuellen Workspace auszulösen. Das ist eine dieser kleinen Quality-of-Life-Verbesserungen, die jede Interaktion beschleunigen — keine vollständigen Dateipfade mehr beim Verweisen auf Code.

CSS `@import` Link-Auflösung

Schön für Frontend-Entwickler: VS Code löst jetzt CSS @import-Referenzen auf, die node_modules-Pfade verwenden. Ihr könnt durch Imports wie @import "some-module/style.css" mit Ctrl+Klick navigieren, wenn ihr Bundler nutzt. Klein, aber es eliminiert einen Reibungspunkt in CSS-Workflows.

Fazit

VS Code 1.116 dreht sich um Verfeinerung — die Agents App navigierbarer, barrierefreier und tastaturfreundlicher zu machen. Wenn ihr viel Zeit in der Agents App verbringt (und ich vermute, das tun viele von uns), summieren sich diese Änderungen.

Schaut euch die vollständigen Release Notes für die komplette Liste an.

VS Code 1.115 — Hintergrund-Terminal-Benachrichtigungen, SSH-Agent-Modus und Mehr

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

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

VS Code 1.115 ist gerade erschienen, und obwohl es ein leichteres Release in Bezug auf Hauptfeatures ist, sind die agentenbezogenen Verbesserungen wirklich nützlich, wenn man täglich mit KI-Coding-Assistenten arbeitet.

Lass mich hervorheben, was wirklich wissenswert ist.

Hintergrund-Terminals kommunizieren mit Agenten

Das ist das herausragende Feature. Hintergrund-Terminals benachrichtigen Agenten jetzt automatisch, wenn Befehle abgeschlossen sind, einschließlich Exit-Code und Terminal-Ausgabe. Eingabeaufforderungen in Hintergrund-Terminals werden ebenfalls erkannt und dem Benutzer angezeigt.

Warum ist das wichtig? Wenn du Copilots Agent-Modus verwendet hast, um Build-Befehle oder Test-Suites im Hintergrund auszuführen, kennst du den Schmerz von “Ist das schon fertig?” — Hintergrund-Terminals waren im Wesentlichen Fire-and-Forget. Jetzt wird der Agent benachrichtigt, wenn dein dotnet build oder dotnet test abgeschlossen ist, sieht die Ausgabe und kann entsprechend reagieren. Es ist eine kleine Änderung, die agentengesteuerte Workflows deutlich zuverlässiger macht.

Es gibt auch ein neues send_to_terminal-Tool, das Agenten ermöglicht, Befehle mit Benutzerbestätigung an Hintergrund-Terminals zu senden. Das behebt das Problem, bei dem run_in_terminal mit einem Timeout Terminals in den Hintergrund verschob und sie schreibgeschützt machte.

SSH-Remote-Agent-Hosting

VS Code unterstützt jetzt die Verbindung zu Remote-Maschinen über SSH, installiert automatisch die CLI und startet sie im Agent-Host-Modus. Das bedeutet, dass deine KI-Agent-Sitzungen direkt auf Remote-Umgebungen zielen können — nützlich für .NET-Entwickler, die auf Linux-Servern oder Cloud-VMs bauen und testen.

Edit-Tracking in Agent-Sitzungen

Dateiänderungen während Agent-Sitzungen werden jetzt verfolgt und wiederhergestellt, mit Diffs, Undo/Redo und Zustandswiederherstellung. Wenn ein Agent Änderungen an deinem Code vornimmt und etwas schiefgeht, kannst du genau sehen, was sich geändert hat, und es zurückrollen. Beruhigend, wenn man Agenten seine Codebasis ändern lässt.

Browser-Tab-Erkennung und weitere Verbesserungen

Ein paar weitere Quality-of-Life-Ergänzungen:

Browser-Tab-Tracking — Chat kann jetzt Browser-Tabs verfolgen und verlinken, die während einer Sitzung geöffnet wurden, sodass Agenten auf Webseiten verweisen können, die du gerade anschaust
Dateieinfügen im Terminal — füge Dateien (einschließlich Bilder) mit Strg+V, Drag-and-Drop oder Rechtsklick in das Terminal ein
Testabdeckung in der Minimap — Testabdeckungsindikatoren werden jetzt in der Minimap für einen schnellen visuellen Überblick angezeigt
Pinch-to-Zoom auf Mac — der integrierte Browser unterstützt Pinch-to-Zoom-Gesten
Copilot-Berechtigungen in Sitzungen — die Statusleiste zeigt Nutzungsinformationen in der Sitzungsansicht
Favicon in Gehe zu Datei — geöffnete Webseiten zeigen Favicons in der Schnellauswahlliste

Fazit

VS Code 1.115 ist ein inkrementelles Release, aber die Agent-Verbesserungen — Hintergrund-Terminal-Benachrichtigungen, SSH-Agent-Hosting und Edit-Tracking — ergeben zusammen eine spürbar flüssigere Erfahrung für KI-unterstützte Entwicklung. Wenn du Copilots Agent-Modus für .NET-Projekte verwendest, sind das genau die Art von Quality-of-Life-Verbesserungen, die den täglichen Reibungsverlust reduzieren.

Schau dir die vollständigen Release Notes für alle Details an.

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.

azd ermöglicht jetzt lokales Ausführen und Debuggen von KI-Agenten — Das hat sich im März 2026 geändert

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

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

Sieben Releases in einem Monat. Das hat das Azure Developer CLI (azd)-Team im März 2026 veröffentlicht, und das Hauptfeature ist genau das, worauf ich gewartet habe: ein lokaler Run-and-Debug-Loop für KI-Agenten.

PC Chan hat die vollständige Zusammenfassung veröffentlicht, und obwohl es viel gibt, lass mich das auf das filtern, was für .NET-Entwickler, die KI-gestützte Apps bauen, wirklich wichtig ist.

KI-Agenten ausführen und debuggen ohne Deployment

Das ist das große Ding. Die neue azure.ai.agents-Extension fügt Befehle hinzu, die dir eine ordentliche Inner-Loop-Erfahrung für KI-Agenten geben:

azd ai agent run — startet deinen Agenten lokal
azd ai agent invoke — sendet Nachrichten (lokal oder deployed)
azd ai agent show — zeigt Container-Status und Health
azd ai agent monitor — streamt Container-Logs in Echtzeit

Vorher bedeutete das Testen eines KI-Agenten jedes Mal ein Deployment zu Microsoft Foundry. Jetzt kannst du lokal iterieren, das Verhalten testen und erst deployen, wenn du bereit bist. Wenn du Agenten mit dem Microsoft Agent Framework oder Semantic Kernel baust, ändert das deinen täglichen Workflow.

Der invoke-Befehl funktioniert sowohl gegen lokale als auch deployed Agenten, was bedeutet, dass du den gleichen Test-Workflow verwenden kannst, egal wo der Agent läuft.

GitHub Copilot richtet dein azd-Projekt ein

azd init bietet jetzt eine “Set up with GitHub Copilot (Preview)"-Option. Statt manuell Prompts über deine Projektstruktur zu beantworten, scaffoldet ein Copilot-Agent die Konfiguration für dich. Wenn ein Befehl fehlschlägt, bietet azd jetzt KI-gestützte Fehlerbehebung: Kategorie wählen, den Agenten einen Fix vorschlagen lassen und wiederholen — alles ohne das Terminal zu verlassen.

Container App Jobs und Deployment-Verbesserungen

Container App Jobs: azd deployed jetzt Microsoft.App/jobs über die bestehende host: containerapp-Konfiguration.
Konfigurierbare Deployment-Timeouts: Neues --timeout-Flag und deployTimeout-Feld in azure.yaml.
Remote-Build-Fallback: Bei fehlgeschlagenem ACR-Build fällt azd automatisch auf lokalen Docker/Podman-Build zurück.
Lokale Preflight-Validierung: Bicep-Parameter werden lokal validiert, bevor deployed wird.

DX-Verbesserungen

Automatische pnpm/yarn-Erkennung für JS/TS-Projekte
pyproject.toml-Unterstützung für Python
Lokale Template-Verzeichnisse — azd init --template akzeptiert jetzt Dateisystem-Pfade
Bessere Fehlermeldungen im --no-prompt-Modus
Build-Umgebungsvariablen in alle Framework-Build-Subprozesse injiziert (.NET, Node.js, Java, Python)

Zusammenfassung

Der lokale KI-Agenten-Debug-Loop ist der Star dieses Releases, aber die Gesamtheit an Deployment-Verbesserungen und DX-Polish macht azd reifer als je zuvor. Wenn du .NET-Apps auf Azure deployst — besonders KI-Agenten — lohnt sich dieses Update.

Schau dir die vollständigen Release Notes für alle Details an.

Azure DevOps behebt endlich den Markdown-Editor, über den sich alle beschwert haben

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

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

Wenn du Azure Boards benutzt, hast du das wahrscheinlich erlebt: Du liest eine Work-Item-Beschreibung durch, vielleicht überprüfst du Akzeptanzkriterien, und du machst versehentlich einen Doppelklick. Boom — du bist im Bearbeitungsmodus. Du wolltest nichts bearbeiten. Du hast nur gelesen.

Dan Hellem hat den Fix angekündigt, und es ist eine dieser Änderungen, die klein klingen, aber echte Reibung aus deinem täglichen Workflow entfernen.

Was sich geändert hat

Der Markdown-Editor für Work-Item-Textfelder öffnet jetzt standardmäßig im Vorschaumodus. Du kannst den Inhalt lesen und damit interagieren — Links folgen, Formatierung überprüfen — ohne dir Sorgen zu machen, versehentlich in den Bearbeitungsmodus zu gelangen.

Wenn du wirklich bearbeiten willst, klickst du auf das Bearbeiten-Symbol oben am Feld. Wenn du fertig bist, verlässt du den Modus explizit. Einfach, bewusst, vorhersagbar.

Warum das wichtiger ist als es klingt

Der Community-Feedback-Thread dazu war lang. Das Doppelklick-zum-Bearbeiten-Verhalten wurde im Juli 2025 mit dem Markdown-Editor eingeführt, und die Beschwerden begannen fast sofort.

Für Teams, die Sprint-Planung, Backlog-Pflege oder Code-Reviews mit Azure Boards machen, summiert sich diese Mikro-Reibung. Jeder versehentliche Bearbeitungsmodus-Eintritt ist ein Kontextwechsel.

Rollout-Status

Dies wird bereits an einen Teil der Kunden ausgerollt und über die nächsten zwei bis drei Wochen auf alle erweitert.

Zusammenfassung

Nicht jede Verbesserung muss ein Headliner sein. Manchmal ist das beste Update einfach etwas Nerviges zu entfernen. Das hier ist genau so eine — ein kleiner UX-Fix, der Azure Boards weniger feindselig für Leute macht, die einfach nur ihre Work Items in Ruhe lesen wollen.

Bookmark Studio bringt Slot-basierte Navigation und Sharing zu Visual Studio Bookmarks

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

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

Bookmarks in Visual Studio waren schon immer… okay. Du setzt eines, navigierst zum nächsten, vergisst welches welches ist. Sie funktionieren, aber sie waren nie eine Funktion, die man als mächtig bezeichnen würde.

Mads Kristensen hat gerade Bookmark Studio veröffentlicht, eine experimentelle Extension, die genau die Lücken füllt, auf die du wahrscheinlich gestoßen bist.

Bookmarks können Slots 1–9 zugewiesen und direkt mit Alt+Shift+1 bis Alt+Shift+9 angesprungen werden. Neue Bookmarks bekommen automatisch den nächsten verfügbaren Slot.

Der Bookmark Manager

Ein neues Tool-Fenster zeigt alle Bookmarks mit Filterung nach Name, Datei, Ort, Farbe oder Slot.

Organisation mit Labels, Farben und Ordnern

Bookmarks können optional Labels, Farben haben und in Ordner gruppiert werden. Alle Metadaten werden pro Solution gespeichert.

Exportieren und Teilen

Bookmark Studio ermöglicht den Export als Klartext, Markdown oder CSV. Bookmark-Pfade in PR-Beschreibungen einbinden oder Untersuchungspfade mit Teamkollegen teilen.

Bookmarks die dem Code folgen

Bookmark Studio verfolgt Bookmarks relativ zum verankerten Text, sodass sie nicht auf falsche Zeilen driften.

Zusammenfassung

Bookmark Studio erfindet nichts neu. Es nimmt ein Feature, das jahrelang „gut genug" war, und macht es wirklich nützlich. Hol es dir vom Visual Studio Marketplace.

Visual Studios März-Update lässt dich eigene Copilot-Agenten bauen — und find_symbol ist ein großes Ding

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

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

Visual Studio hat gerade sein bedeutendstes Copilot-Update bekommen. Mark Downie hat das März-Release angekündigt, und die Überschrift sind Custom Agents — aber ehrlich gesagt könnte das find_symbol-Tool weiter unten die Funktion sein, die deinen Workflow am meisten verändert.

Benutzerdefinierte Copilot-Agenten in deinem Repo

Willst du, dass Copilot deinen Team-Codierstandards folgt, deine Build-Pipeline ausführt oder deine internen Docs abfragt? Jetzt kannst du genau das bauen.

Custom Agents werden als .agent.md-Dateien definiert, die du in .github/agents/ in deinem Repository ablegst. Jeder Agent hat vollen Zugriff auf Workspace-Awareness, Code-Verständnis, Tools, dein bevorzugtes Modell und MCP-Verbindungen.

Agent Skills: wiederverwendbare Instruktionspakete

Skills werden automatisch aus .github/skills/ in deinem Repo oder ~/.copilot/skills/ in deinem Profil geladen. Denke an Skills als modulare Expertise, die du mischen und kombinieren kannst.

Das neue find_symbol-Tool gibt Copilots Agent-Modus sprachservice-gestützte Symbol-Navigation. Statt Text zu suchen, kann der Agent alle Referenzen eines Symbols finden und auf Typ-Informationen, Deklarationen und Scope zugreifen.

Für .NET-Entwickler ist das eine massive Verbesserung — C#-Codebasen mit tiefen Typ-Hierarchien profitieren enorm.

Tests mit Copilot profilen

Im Test Explorer gibt es jetzt Profile with Copilot. Der Profiling Agent führt den Test aus und analysiert automatisch CPU-Nutzung und Instrumentierungsdaten.

Perf Tips beim Live-Debugging

Performance-Optimierung passiert jetzt während des Debuggens. Visual Studio zeigt inline Ausführungszeit und Performance-Signale. Siehst du eine langsame Zeile? Klicke auf den Perf Tip und frage Copilot nach Optimierungsvorschlägen.

NuGet-Schwachstellen aus dem Solution Explorer beheben

Bei erkannten NuGet-Schwachstellen siehst du einen Fix with GitHub Copilot-Link direkt im Solution Explorer.

Zusammenfassung

Custom Agents und Skills sind die Überschrift, aber find_symbol ist der Sleeper Hit — es verändert grundlegend, wie genau Copilot beim Refactoring von .NET-Code sein kann. Kombiniert mit Live-Profiling und Schwachstellen-Fixes fühlen sich die KI-Features von Visual Studio jetzt wirklich praktisch an.

Lade Visual Studio 2026 Insiders herunter, um alles auszuprobieren.

Vom Laptop in die Produktion: KI-Agenten mit zwei Befehlen auf Microsoft Foundry deployen

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Du kennst diese Lücke zwischen “es funktioniert auf meinem Rechner” und “es ist deployed und bedient Traffic”? Für KI-Agenten war diese Lücke schmerzhaft groß. Du musst Ressourcen bereitstellen, Modelle deployen, Identität einrichten, Monitoring aufsetzen — und das ist bevor jemand deinen Agenten überhaupt aufrufen kann.

Das Azure Developer CLI hat das gerade zu einer Zwei-Befehle-Angelegenheit gemacht.

Der neue `azd ai agent` Workflow

Lass mich durchgehen, wie das tatsächlich aussieht. Du hast ein KI-Agenten-Projekt — sagen wir einen Hotel-Concierge-Agenten. Er funktioniert lokal. Du willst ihn auf Microsoft Foundry laufen lassen.

azd ai agent init
azd up

Das war’s. Zwei Befehle. azd ai agent init generiert die Infrastructure-as-Code in deinem Repo, und azd up provisioniert alles auf Azure und veröffentlicht deinen Agenten. Du bekommst einen direkten Link zu deinem Agenten im Foundry-Portal.

Was unter der Haube passiert

Der init-Befehl generiert echte, inspizierbare Bicep-Templates in deinem Repo:

Eine Foundry Resource (Top-Level-Container)
Ein Foundry Project (wo dein Agent lebt)
Modell-Deployment-Konfiguration (GPT-4o, etc.)
Managed Identity mit korrekten RBAC-Rollenzuweisungen
azure.yaml für die Service-Map
agent.yaml mit Agent-Metadaten und Umgebungsvariablen

Hier der entscheidende Punkt: all das gehört dir. Es ist versioniertes Bicep in deinem Repo. Du kannst es inspizieren, anpassen und zusammen mit deinem Agenten-Code committen. Keine magischen Black Boxes.

Die innere Entwicklungsschleife

Was mir wirklich gefällt, ist die lokale Entwicklungsgeschichte. Wenn du an der Agenten-Logik iterierst, willst du nicht bei jeder Prompt-Änderung neu deployen:

azd ai agent run

Das startet deinen Agenten lokal. Kombiniere es mit azd ai agent invoke um Test-Prompts zu senden, und du hast eine enge Feedback-Schleife. Code bearbeiten, neu starten, aufrufen, wiederholen.

Der invoke-Befehl ist auch clever beim Routing — wenn ein lokaler Agent läuft, zielt er automatisch darauf. Wenn nicht, geht er an den Remote-Endpoint.

Echtzeit-Monitoring

Das ist die Funktion, die mich überzeugt hat. Sobald dein Agent deployed ist:

azd ai agent monitor --follow

Jede Anfrage und Antwort, die durch deinen Agenten fließt, wird in Echtzeit in dein Terminal gestreamt. Für das Debugging von Produktionsproblemen ist das unbezahlbar. Kein Durchsuchen von Log Analytics, kein Warten auf Metrik-Aggregation — du siehst, was gerade passiert.

Der komplette Befehlssatz

Hier die Kurzreferenz:

Befehl	Was er tut
`azd ai agent init`	Scaffolding eines Foundry-Agent-Projekts mit IaC
`azd up`	Azure-Ressourcen bereitstellen und Agent deployen
`azd ai agent invoke`	Prompts an den Remote- oder lokalen Agent senden
`azd ai agent run`	Agent lokal für Entwicklung ausführen
`azd ai agent monitor`	Echtzeit-Logs vom veröffentlichten Agent streamen
`azd ai agent show`	Agent-Gesundheit und -Status prüfen
`azd down`	Alle Azure-Ressourcen aufräumen

Warum das für .NET-Entwickler wichtig ist

Auch wenn das Beispiel in der Ankündigung Python-basiert ist, ist die Infrastruktur-Geschichte sprachunabhängig. Dein .NET-Agent bekommt das gleiche Bicep-Scaffolding, das gleiche Managed-Identity-Setup, die gleiche Monitoring-Pipeline. Und wenn du azd bereits für deine .NET Aspire-Apps oder Azure-Deployments nutzt, passt das direkt in deinen bestehenden Workflow.

Die Deployment-Lücke für KI-Agenten war einer der größten Reibungspunkte im Ökosystem. Von einem funktionierenden Prototyp zu einem Produktions-Endpoint mit korrekter Identität, Networking und Monitoring zu kommen, sollte keine Woche DevOps-Arbeit erfordern. Jetzt braucht es zwei Befehle und ein paar Minuten.

Zusammenfassung

azd ai agent ist jetzt verfügbar. Wenn du das Deployment deiner KI-Agenten aufgeschoben hast, weil das Infrastruktur-Setup nach zu viel Arbeit aussah, probier es aus. Schau dir den vollständigen Walkthrough für die komplette Schritt-für-Schritt-Anleitung inklusive Frontend-Chat-App-Integration an.