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

Visual Studio 2026 April-Update: Cloud-Agent, benutzerdefinierte Agents und Debugger-Agent

Emiliano Montesdeoca — Thu, 14 May 2026 00:00:00 +0000

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

Das April-Update von Visual Studio 2026 (18.5) liefert Cloud-Agent-Integration, benutzerbezogene benutzerdefinierte Agents, C++-Tools die GA erreichen, und einen neuen Debugger-Agent.

Cloud-Agent: Arbeit an eine Remote-Copilot-Sitzung delegieren

Im Agent-Picker des Chat-Fensters können Sie durch Auswahl von Cloud eine Aufgabe an einen Remote-Copilot-Coding-Agent übergeben. Sie beschreiben die Arbeit, der Agent erstellt ein GitHub-Issue in Ihrem Repository und öffnet einen PR, wenn er fertig ist. Sie erhalten eine Benachrichtigung mit “View PR” / “Open in browser” — das Ganze läuft, während Sie weiterarbeiten oder sogar mit geschlossener IDE.

Benutzerdefinierte Agents begleiten Sie jetzt überall

Benutzerbezogene benutzerdefinierte Agents unter %USERPROFILE%/.github/agents/ sind nicht mehr auf ein Repository beschränkt — sie begleiten Sie projektübergreifend. Der Speicherpfad ist unter Tools > Optionen > GitHub > Copilot > Chat konfigurierbar. Die +-Schaltfläche im Agent-Picker ermöglicht die direkte Erstellung neuer Agents. Sie erhalten dieselben Fähigkeiten wie repository-bezogene Agents: Arbeitsbereichsbewusstsein, Tools, Modellauswahl und MCP-Verbindungen.

Integrierte Agents: Agent, Ask, Copilot CLI, Debugger, Modernize, Profiler.

C++-Code-Editing-Tools werden GA

Zwei Tools — get_symbol_call_hierarchy und get_symbol_class_hierarchy — sind jetzt standardmäßig aktiviert. Sie geben Copilot sprachbewusste Navigation durch C++-Codebasen und decken Vererbungshierarchien sowie Funktionsaufrufketten ab. Aktivierung über das Tools-Symbol im Copilot Chat. Funktioniert am besten mit Tool-Calling-Modellen.

Debugger-Agent: Fixes werden gegen echtes Laufzeitverhalten validiert

Starten Sie von einem GitHub- oder Azure-DevOps-Issue (oder einer Beschreibung in natürlicher Sprache), wechseln Sie in den Debugger-Modus, und der Agent:

Erstellt einen minimalen Reproducer
Generiert Fehlerhypothesen
Instrumentiert die App mit Tracepoints und bedingten Breakpoints
Führt eine echte Debug-Sitzung durch
Analysiert Live-Telemetrie
Schlägt eine präzise Lösung vor

Sie bleiben während des gesamten Prozesses eingebunden — es ist interaktiv, nicht vollständig autonom.

IntelliSense-Prioritätskorrektur

VS unterdrückt jetzt Copilot-Vervollständigungen, während die IntelliSense-Liste aktiv ist. Jeweils nur ein Vorschlag. Dies war ein häufiger Reibungspunkt und ist jetzt standardmäßig aktiviert.

Vollständige Release-Notes und Download auf devblogs.microsoft.com.

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.

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.

VS Code 1.112: Was .NET-Entwickler wirklich interessieren sollte

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

VS Code 1.112 ist gelandet, und ehrlich? Dieses Release fühlt sich anders an, wenn du deine Tage in der .NET-Welt verbringst. Es gibt viel in den offiziellen Release Notes, aber lass mich dir etwas Scrollen ersparen und mich auf das konzentrieren, was für uns wirklich zählt.

Copilot CLI ist gerade viel nützlicher geworden

Das große Thema dieses Releases ist Agent-Autonomie — Copilot mehr Raum geben, sein Ding zu machen, ohne dass du jeden Schritt überwachst.

Nachrichtensteuerung und Warteschlange

Kennst du den Moment, wenn Copilot CLI mitten in einer Aufgabe ist und dir auffällt, dass du etwas vergessen hast zu erwähnen? Vorher musstest du warten. Jetzt kannst du Nachrichten senden, während eine Anfrage noch läuft — entweder um die aktuelle Antwort zu steuern oder Folgeanweisungen in die Warteschlange zu stellen.

Das ist riesig für die längeren dotnet-Scaffolding-Aufgaben, wo du Copilot beim Projekt-Setup zuschaust und denkst “oh warte, ich brauche auch MassTransit da drin.”

Berechtigungsstufen

Das ist die Funktion, die mich am meisten begeistert. Copilot CLI-Sitzungen unterstützen jetzt drei Berechtigungsstufen:

Standard-Berechtigungen — der übliche Flow, bei dem Tools vor dem Ausführen um Bestätigung bitten
Genehmigungen umgehen — genehmigt alles automatisch und wiederholt bei Fehlern
Autopilot — wird voll autonom: genehmigt Tools, beantwortet eigene Fragen und macht weiter, bis die Aufgabe erledigt ist

Wenn du etwas wie das Scaffolding einer neuen ASP.NET Core API mit Entity Framework, Migrationen und Docker-Setup machst — Autopilot-Modus bedeutet, du beschreibst was du willst und holst dir einen Kaffee. Er wird es herausfinden.

Du kannst Autopilot mit der Einstellung chat.autopilot.enabled aktivieren.

Änderungen vor der Delegation vorschauen

Wenn du eine Aufgabe an Copilot CLI delegierst, erstellt er einen Worktree. Vorher, wenn du nicht committete Änderungen hattest, musstest du die Quellcodeverwaltung prüfen, um zu sehen, was betroffen wäre. Jetzt zeigt die Chat-Ansicht ausstehende Änderungen direkt dort an, bevor du entscheidest, ob du sie kopieren, verschieben oder ignorieren willst.

Kleine Sache, aber es erspart dir den “warte, was hatte ich gestaged?"-Moment.

Web-Apps debuggen ohne VS Code zu verlassen

Der integrierte Browser unterstützt jetzt vollständiges Debugging. Du kannst Breakpoints setzen, durch Code steppen und Variablen inspizieren — alles in VS Code. Kein Wechsel mehr zu Edge DevTools.

Es gibt einen neuen editor-browser Debug-Typ, und wenn du bereits vorhandene msedge- oder chrome-Launch-Konfigurationen hast, ist die Migration so einfach wie das Ändern des type-Felds in deiner launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Für Blazor-Entwickler ist das ein Game Changer. Du führst bereits dotnet watch im Terminal aus — jetzt bleibt dein Debugging auch im selben Fenster.

Der Browser hat auch unabhängige Zoom-Stufen bekommen (endlich), richtige Rechtsklick-Kontextmenüs, und der Zoom wird pro Website gespeichert.

MCP-Server-Sandboxing

Das ist wichtiger als du vielleicht denkst. Wenn du MCP-Server verwendest — vielleicht hast du einen für deine Azure-Ressourcen oder Datenbankabfragen eingerichtet — liefen sie bisher mit denselben Berechtigungen wie dein VS Code-Prozess. Das bedeutet voller Zugriff auf dein Dateisystem, Netzwerk, alles.

Jetzt kannst du sie sandboxen. In deiner mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Wenn ein gesandboxter Server Zugriff auf etwas braucht, das er nicht hat, fordert VS Code dich auf, die Berechtigung zu erteilen. Viel besser als der “hoffen wir, dass niemand etwas Merkwürdiges macht”-Ansatz.

Hinweis: Sandboxing ist derzeit auf macOS und Linux verfügbar. Windows-Support kommt — Remote-Szenarien wie WSL funktionieren aber bereits.

Monorepo-Customization-Discovery

Wenn du in einem Monorepo arbeitest (und seien wir ehrlich, viele Enterprise-.NET-Lösungen enden als eines), löst das einen echten Schmerzpunkt.

Zuvor, wenn du einen Unterordner deines Repos geöffnet hast, fand VS Code deine copilot-instructions.md, AGENTS.md oder benutzerdefinierten Skills nicht, die im Repository-Root lagen. Jetzt mit der Einstellung chat.useCustomizationsInParentRepositories geht es bis zum .git-Root hoch und entdeckt alles.

Das bedeutet, dein Team kann Agent-Anweisungen, Prompt-Dateien und benutzerdefinierte Tools über alle Projekte in einem Monorepo teilen, ohne dass jeder den Root-Ordner öffnen muss.

/troubleshoot für Agent-Debugging

Hast du jemals benutzerdefinierte Anweisungen oder Skills eingerichtet und dich gefragt, warum sie nicht erkannt werden? Der neue /troubleshoot-Skill liest Agent-Debug-Logs und sagt dir, was passiert ist — welche Tools verwendet oder übersprungen wurden, warum Anweisungen nicht geladen wurden und was langsame Antworten verursacht.

Aktiviere es mit:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Dann tippe einfach /troubleshoot why is my custom skill not loading? im Chat.

Du kannst diese Debug-Logs jetzt auch exportieren und importieren, was großartig ist, um sie mit deinem Team zu teilen, wenn etwas nicht wie erwartet funktioniert.

Bild- und Binärdatei-Unterstützung

Agenten können jetzt Bilddateien von der Festplatte und Binärdateien nativ lesen. Binärdateien werden im Hexdump-Format präsentiert, und Bildausgaben (wie Screenshots vom integrierten Browser) erscheinen in einer Karussell-Ansicht.

Für .NET-Entwickler denke: füge einen Screenshot eines UI-Bugs in den Chat ein und lass den Agenten verstehen, was falsch ist, oder lass ihn die Ausgabe eines Blazor-Komponenten-Renderings analysieren.

Automatische Symbol-Referenzen

Kleine Qualitäts-Verbesserung: wenn du einen Symbolnamen (eine Klasse, Methode, etc.) kopierst und in den Chat einfügst, konvertiert VS Code ihn jetzt automatisch in eine #sym:Name-Referenz. Das gibt dem Agenten vollen Kontext über das Symbol, ohne dass du es manuell hinzufügen musst.

Wenn du stattdessen reinen Text möchtest, verwende Ctrl+Shift+V.

Plugins können jetzt aktiviert/deaktiviert werden

Zuvor bedeutete das Deaktivieren eines MCP-Servers oder Plugins, ihn zu deinstallieren. Jetzt kannst du sie an- und ausschalten — sowohl global als auch pro Workspace. Rechtsklick in der Erweiterungsansicht oder der Customization-Ansicht und fertig.

Plugins von npm und pypi können sich jetzt auch automatisch aktualisieren, obwohl sie zuerst um Genehmigung bitten, da Updates bedeuten, dass neuer Code auf deinem Rechner ausgeführt wird.

Zusammenfassung

VS Code 1.112 pusht eindeutig hart auf die Agent-Experience — mehr Autonomie, besseres Debugging, engere Sicherheit. Für .NET-Entwickler sind das integrierte Browser-Debugging und die Copilot CLI-Verbesserungen die herausragenden Features.

Wenn du noch keine vollständige Copilot CLI-Sitzung im Autopilot-Modus für ein .NET-Projekt ausprobiert hast, ist dieses Release ein guter Zeitpunkt zum Starten. Denk nur daran, deine Berechtigungen einzustellen und es machen zu lassen.

VS Code 1.112 herunterladen oder innerhalb von VS Code aktualisieren über Hilfe > Nach Updates suchen.