GitHub Copilot | The .NET Blog

Azure DevOps MCP Server April Update: WIQL-Abfragen, PAT-Auth und experimentelle MCP Apps

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

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

Der Azure DevOps MCP Server verbessert sich kontinuierlich. Das April-Update von Dan Hellem deckt beide Server ab.

WIQL-Abfrageunterstützung

Das neue wit_query_by_wiql-Tool ermöglicht Work Item Query Language Abfragen direkt aus deinem MCP-Client.

Personal Access Tokens

PAT-Authentifizierung am lokalen Server — wichtig für Integrationsszenarien ohne interaktive Authentifizierung.

MCP-Annotationen

Metadaten-Tags für Read-only-, Destructive- und Open-World-Tools — grundlegend für Agent-Zuverlässigkeit.

Wiki-Tool-Konsolidierung

5 separate Wiki-Tools → 2 fähigere Tools. Weniger Tools = bessere LLM-Performance.

Experimentell: MCP Apps

Paketierte Workflows innerhalb der MCP-Server-Umgebung. Die Richtung stimmt.

Originalpost von Dan Hellem: Azure DevOps MCP Server April Update.

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.

68 Minuten täglich damit verbracht, Code neu zu erklären? Es gibt eine Lösung

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

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

Kennst du den Moment, wenn deine Copilot-Sitzung /compact trifft und der Agent komplett vergisst, woran du gearbeitet hast? Die nächsten fünf Minuten verbringst du damit, die Dateistruktur, den fehlschlagenden Test und die drei Ansätze, die du bereits versucht hast, neu zu erklären. Dann passiert es wieder. Und wieder.

Desi Villanueva hat es gemessen: 68 Minuten pro Tag — nur für Neuorientierung. Kein Code schreiben. Keine PRs reviewen. Nur die KI über Dinge auf den neuesten Stand bringen, die sie bereits wusste.

Es stellt sich heraus, dass es dafür einen konkreten Grund gibt — und eine konkrete Lösung.

Die Kontextfenster-Lüge

Dein Agent kommt mit einer großen Zahl auf der Verpackung. 200K Tokens. Klingt riesig. In der Praxis ist es eine Obergrenze, keine Garantie.

Hier ist die tatsächliche Rechnung:

200K Gesamtkontext
Minus ~65K für MCP-Tools beim Start (~33%)
Minus ~10K für Instruktionsdateien wie AGENTS.md oder copilot-instructions.md

Das hinterlässt dir etwa 125K bevor du ein einziges Wort schreibst. Und es wird schlimmer — LLMs degradieren nicht graceful wenn der Kontext voll wird. Sie stoßen an eine Wand bei etwa 60% Auslastung. Das Modell verliert Dinge, die vor 30 Runden erwähnt wurden, widerspricht früheren Antworten und halluziniert Dateinamen, die es vor 10 Minuten noch selbstsicher angegeben hatte.

Effektives Limit: 45K Tokens bevor die Qualität degradiert. Das sind vielleicht 20-30 Runden aktiver Konversation bevor der Agent anfängt abzudriften.

Die Kompaktierungssteuer

Jedes /compact kostet dich deinen Flow-Zustand. Du bist tief in einer Debugging-Sitzung. Gemeinsamer Kontext über 30 Minuten aufgebaut. Der Agent kennt die Dateistruktur, den fehlschlagenden Test, die Hypothese. Dann kommt die Warnung.

Ignorieren → Agent wird progressiv dümmer
/compact ausführen → Agent hat eine 2-Absatz-Zusammenfassung einer 30-minütigen Untersuchung

So oder so verlierst du. So oder so erzählst du dein eigenes Projekt einem neuen Mitarbeiter am ersten Tag nach.

Das Grausame: Die Erinnerung existiert bereits. Copilot CLI schreibt jede Sitzung in eine lokale SQLite-Datenbank bei ~/.copilot/session-store.db. Der Agent kann sie nur nicht lesen.

auto-memory: Eine Recall-Schicht, Kein Gedächtnissystem

pip install auto-memory

~1.900 Zeilen Python. Null Abhängigkeiten. In 30 Sekunden installiert.

Anstatt den Kontext mit Grep-Ergebnissen zu fluten, gibst du dem Agenten chirurgischen Zugriff auf das, was wirklich wichtig ist — 50 Tokens statt 10.000.

Fazit

Context Rot ist eine reale architektonische Einschränkung. auto-memory umgeht sie, indem es deinem Agenten einen günstigen, präzisen Recall-Mechanismus gibt. Wenn du ernsthaftes KI-unterstütztes Entwickeln mit GitHub Copilot CLI machst, ist die 30-Sekunden-Installation es wert.

Schau es dir an: auto-memory auf GitHub. Original-Post von Desi Villanueva: I Wasted 68 Minutes a Day.

azd + GitHub Copilot: KI-gestütztes Projekt-Setup und intelligente Fehlerbehandlung

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die englische Originalversion findest du hier.

Du kennst diesen Moment, wenn du eine bestehende App in Azure deployen möchtest und plötzlich auf eine leere azure.yaml starrst und versuchst zu erinnern, ob deine Express-API Container Apps oder App Service verwenden sollte? Genau dieser Moment wird jetzt deutlich kürzer.

Die Azure Developer CLI (azd) integriert sich jetzt mit GitHub Copilot auf zwei sinnvolle Arten: KI-gestütztes Projekt-Scaffolding während azd init und intelligente Fehlerbehebung, wenn Deployments schiefgehen. Beide Funktionen bleiben vollständig im Terminal — genau dort, wo ich sie haben möchte.

Setup mit Copilot während azd init

Wenn du azd init ausführst, gibt es jetzt die Option “Set up with GitHub Copilot (Preview)”. Wähle sie aus, und Copilot analysiert deine Codebasis, um die azure.yaml, Infrastruktur-Templates und Bicep-Module zu generieren — basierend auf deinem tatsächlichen Code.

azd init
# Wähle: "Set up with GitHub Copilot (Preview)"

Voraussetzungen:

azd 1.23.11 oder neuer — prüfe mit azd version oder aktualisiere mit azd update
Aktives GitHub Copilot-Abonnement (Individual, Business oder Enterprise)
GitHub CLI (gh) — azd fragt bei Bedarf nach dem Login

Was ich dabei wirklich nützlich finde: Es funktioniert in beide Richtungen. Baust du von Grund auf neu? Copilot hilft dir, von Anfang an die richtigen Azure-Services einzurichten. Hast du eine bestehende App, die du schon länger deployen wolltest? Zeig Copilot auf sie, und er generiert die Konfiguration, ohne dass du irgendetwas umstrukturieren musst.

Was es wirklich macht

Angenommen, du hast eine Node.js Express-API mit PostgreSQL-Abhängigkeit. Statt manuell zwischen Container Apps und App Service zu entscheiden und dann Bicep von Grund auf zu schreiben, erkennt Copilot deinen Stack und generiert:

Eine azure.yaml mit den richtigen language-, host- und build-Einstellungen
Ein Bicep-Modul für Azure Container Apps
Ein Bicep-Modul für Azure Database for PostgreSQL

Vor jeder Änderung werden Vorab-Prüfungen durchgeführt — das Git-Arbeitsverzeichnis wird auf Sauberkeit geprüft, und MCP-Server-Tool-Zustimmung wird im Voraus eingeholt. Nichts passiert, ohne dass du genau weißt, was sich ändert.

Copilot-gestützte Fehlerbehebung

Deployment-Fehler sind unvermeidlich. Fehlende Parameter, Berechtigungsprobleme, SKU-Verfügbarkeitsprobleme — und die Fehlermeldung sagt dir selten das eine, was du wirklich wissen musst: wie du es behebst.

Ohne Copilot sieht die Schleife so aus: Fehler kopieren → Docs durchsuchen → drei irrelevante Stack-Overflow-Antworten lesen → einige az-CLI-Befehle ausführen → nochmal versuchen und hoffen. Mit Copilot, der in azd integriert ist, kollabiert diese Schleife. Wenn ein azd-Befehl fehlschlägt, bietet er sofort vier Optionen an:

Explain — Klartextbeschreibung, was schiefgelaufen ist
Guidance — Schritt-für-Schritt-Anweisungen zur Behebung
Diagnose and Guide — vollständige Analyse + Copilot wendet die Lösung an (mit deiner Genehmigung) + optionaler Retry
Skip — selbst lösen

Das Entscheidende: Copilot hat bereits Kontext über dein Projekt, den fehlgeschlagenen Befehl und die Fehlerausgabe. Seine Vorschläge sind spezifisch für deine Situation, keine generischen Docs.

Typische Fehler, bei denen das glänzt

Ressourcenanbieter nicht registriert:

ERROR: deployment failed: MissingSubscriptionRegistration:
The subscription is not registered to use namespace 'Microsoft.App'.

Das trifft jeden bei einem ersten Deployment in einem neuen Abonnement. Copilot kann den Provider registrieren und das Deployment automatisch neu starten.

SKU nicht verfügbar:

ERROR: deployment failed: SkuNotAvailable:
The requested VM size 'Standard_D2s_v3' is not available in location 'westus'.

Copilot erklärt, welche VM-Größe oder Region blockiert ist, und schlägt verfügbare Alternativen vor.

Speicherkontoname bereits vergeben:

ERROR: deployment failed: StorageAccountAlreadyTaken:
The storage account named 'myappstorage' is already taken.

Globale Eindeutigkeit erwischt jeden mindestens einmal. Copilot schlägt vor, deinen Umgebungsnamen oder ein zufälliges Suffix zu deinen Bicep-Parametern hinzuzufügen.

Standardverhalten konfigurieren

Wenn du immer die gleiche Option willst, überspringe den interaktiven Prompt:

azd config set copilot.errorHandling.category troubleshoot

Werte: explain, guidance, troubleshoot, fix, skip. Du kannst auch Auto-Fix und Retry aktivieren:

azd config set copilot.errorHandling.fix allow

Zurück zum interaktiven Modus jederzeit:

azd config unset copilot.errorHandling.category

Fazit

Das ist genau die Art von Copilot-Integration, die echten Mehrwert bringt. Probiere es aus, indem du azd update für die neueste Version ausführst, und verwende dann azd init für dein nächstes Projekt.

Den originalen Ankündigungsbeitrag findest du hier.

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.

Agentisches Platform Engineering Wird Realität — Git-APE Zeigt Wie

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

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

Platform Engineering war einer dieser Begriffe, die auf Konferenzen toll klingen, aber normalerweise bedeuten: „Wir haben ein internes Portal und einen Terraform-Wrapper gebaut." Das eigentliche Versprechen — Self-Service-Infrastruktur, die wirklich sicher, kontrolliert und schnell ist — war immer noch ein paar Schritte entfernt.

Das Azure-Team hat gerade Teil 2 ihrer Serie über agentisches Platform Engineering veröffentlicht, und in diesem Teil geht es um die praktische Umsetzung. Sie nennen es Git-APE (ja, das Akronym ist beabsichtigt), und es ist ein Open-Source-Projekt, das GitHub Copilot Agents plus Azure MCP Server nutzt, um natürlichsprachliche Anfragen in validierte, deployed Infrastruktur umzuwandeln.

Was Git-APE tatsächlich macht

Die Kernidee: Anstatt dass Entwickler Terraform-Module lernen, durch Portal-UIs navigieren oder Tickets beim Platform-Team einreichen, sprechen sie mit einem Copilot-Agenten. Der Agent interpretiert die Absicht, generiert Infrastructure-as-Code, validiert sie gegen Richtlinien und deployt — alles innerhalb von VS Code.

Hier ist das Setup:

git clone https://github.com/Azure/git-ape
cd git-ape

Öffne den Workspace in VS Code, und die Agent-Konfigurationsdateien werden automatisch von GitHub Copilot erkannt. Du interagierst direkt mit dem Agenten:

@git-ape deploy a function app with storage in West Europe

Der Agent nutzt Azure MCP Server unter der Haube, um mit Azure-Diensten zu interagieren. Die MCP-Konfiguration in den VS Code-Einstellungen aktiviert spezifische Fähigkeiten:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Warum das wichtig ist

Für diejenigen von uns, die auf Azure bauen, verschiebt dies die Platform-Engineering-Diskussion von „wie bauen wir ein Portal" zu „wie beschreiben wir unsere Leitplanken als APIs." Wenn die Schnittstelle deiner Plattform ein KI-Agent ist, wird die Qualität deiner Einschränkungen und Richtlinien zum Produkt.

Der Blog von Teil 1 legte die Theorie dar: gut beschriebene APIs, Kontrollschemata und explizite Leitplanken machen Plattformen agent-ready. Teil 2 beweist, dass es funktioniert, indem tatsächliche Werkzeuge ausgeliefert werden. Der Agent generiert nicht blind Ressourcen — er validiert gegen Best Practices, respektiert Namenskonventionen und wendet die Richtlinien deiner Organisation an.

Das Aufräumen ist genauso einfach:

@git-ape destroy my-resource-group

Meine Einschätzung

Ich bin ehrlich — hier geht es mehr um das Muster als um das spezifische Tool. Git-APE selbst ist eine Demo/Referenzarchitektur. Aber die zugrundeliegende Idee — Agenten als Interface zu deiner Plattform, MCP als Protokoll, GitHub Copilot als Host — ist die Richtung, in die sich die Enterprise-Developer-Experience bewegt.

Wenn du ein Platform-Team bist, das darüber nachdenkt, wie man interne Werkzeuge agent-freundlich macht, gibt es keinen besseren Startpunkt. Und wenn du ein .NET-Entwickler bist, der sich fragt, wie das mit deiner Welt zusammenhängt: Der Azure MCP Server und GitHub Copilot Agents funktionieren mit jedem Azure-Workload. Deine ASP.NET Core API, dein .NET Aspire Stack, deine containerisierten Microservices — all das kann Ziel eines agentischen Deployment-Flows sein.

Zusammenfassung

Git-APE ist ein früher, aber konkreter Blick auf agentisches Platform Engineering in der Praxis. Klone das Repo, probiere die Demo aus und fange an darüber nachzudenken, wie die APIs und Richtlinien deiner Plattform aussehen müssten, damit ein Agent sie sicher nutzen kann.

Lies den vollständigen Post für den Walkthrough und Video-Demos.

GitHub Copilots Modernisierungs-Assessment ist das beste Migrationstool, das du noch nicht nutzt

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

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

Eine Legacy-.NET-Framework-App auf modernes .NET zu migrieren ist eine dieser Aufgaben, von der jeder weiß, dass sie erledigt werden sollte, die aber niemand anfangen will. Es ist nie nur „ändere das Ziel-Framework." Es sind APIs, die verschwunden sind, Pakete, die nicht mehr existieren, Hosting-Modelle, die völlig anders funktionieren, und eine Million kleiner Entscheidungen darüber, was containerisiert, was umgeschrieben und was in Ruhe gelassen werden soll.

Jeffrey Fritz hat gerade einen tiefen Einblick in GitHub Copilots Modernisierungs-Assessment veröffentlicht, und ehrlich? Das ist das beste Migrationstooling, das ich für .NET gesehen habe. Nicht wegen der Code-Generierung — das ist mittlerweile Standard. Wegen des Assessment-Dokuments, das es erstellt.

Es ist nicht nur eine Code-Vorschlagsmaschine

Die VS Code-Erweiterung folgt einem Bewerten → Planen → Ausführen-Modell. Die Bewertungsphase analysiert deine gesamte Codebase und erstellt ein strukturiertes Dokument, das alles erfasst: was sich ändern muss, welche Azure-Ressourcen provisioniert werden müssen, welches Deployment-Modell verwendet werden soll. Alles Nachfolgende — Infrastructure as Code, Containerisierung, Deployment-Manifeste — leitet sich aus den Ergebnissen des Assessments ab.

Das Assessment wird unter .github/modernize/assessment/ in deinem Projekt gespeichert. Jeder Durchlauf erzeugt einen unabhängigen Report, sodass du eine Historie aufbaust und verfolgen kannst, wie sich deine Migrationsposition entwickelt, wenn du Issues behebst.

Zwei Wege zum Start

Empfohlenes Assessment — der schnelle Weg. Wähle aus kuratierten Domains (Java/.NET Upgrade, Cloud Readiness, Sicherheit) und erhalte aussagekräftige Ergebnisse ohne Konfigurationsaufwand. Ideal für einen ersten Blick, wo deine App steht.

Benutzerdefiniertes Assessment — der gezielte Weg. Konfiguriere genau, was analysiert werden soll: Ziel-Compute (App Service, AKS, Container Apps), Ziel-OS, Containerisierungsanalyse. Wähle mehrere Azure-Ziele, um Migrationsansätze nebeneinander zu vergleichen.

Diese Vergleichsansicht ist wirklich nützlich. Eine App mit 3 obligatorischen Issues für App Service könnte 7 für AKS haben. Beides zu sehen hilft bei der Hosting-Entscheidung, bevor man sich auf einen Migrationspfad festlegt.

Die Issue-Aufschlüsselung ist umsetzbar

Jedes Issue kommt mit einem Kritikalitätslevel:

Obligatorisch — muss behoben werden, sonst scheitert die Migration
Potenziell — könnte die Migration beeinflussen, braucht menschliche Beurteilung
Optional — empfohlene Verbesserungen, blockiert die Migration nicht

Und jedes Issue verlinkt zu betroffenen Dateien und Zeilennummern, liefert eine detaillierte Beschreibung dessen, was falsch ist und warum es für deine Zielplattform wichtig ist, gibt konkrete Behebungsschritte (nicht nur „repariere das") und enthält Links zur offiziellen Dokumentation.

Du kannst einzelne Issues an Entwickler weitergeben, und sie haben alles, was sie zum Handeln brauchen. Das ist der Unterschied zwischen einem Tool, das dir sagt „es gibt ein Problem" und einem, das dir sagt, wie du es löst.

Die abgedeckten Upgrade-Pfade

Für .NET spezifisch:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Jeder Upgrade-Pfad hat Erkennungsregeln, die wissen, welche APIs entfernt wurden, welche Patterns kein direktes Äquivalent haben und welche Sicherheitsprobleme Aufmerksamkeit erfordern.

Für Teams, die mehrere Apps verwalten, gibt es auch ein CLI, das Multi-Repo-Batch-Assessments unterstützt — alle Repos klonen, alle bewerten, App-spezifische Reports plus eine aggregierte Portfolio-Ansicht bekommen.

Meine Einschätzung

Wenn du auf Legacy-.NET-Framework-Apps sitzt (und seien wir ehrlich, die meisten Enterprise-Teams tun das), ist dies das Tool zum Starten. Allein das Assessment-Dokument ist die Zeit wert — es verwandelt ein vages „wir sollten modernisieren" in eine konkrete, priorisierte Liste von Arbeitspaketen mit klaren Wegen nach vorn.

Der kollaborative Workflow ist auch clever: Assessments exportieren, mit deinem Team teilen, importieren ohne erneut auszuführen. Architektur-Reviews, bei denen die Entscheider nicht diejenigen sind, die die Tools ausführen? Abgedeckt.

Zusammenfassung

GitHub Copilots Modernisierungs-Assessment verwandelt .NET-Migration von einem beängstigenden, undefinierten Projekt in einen strukturierten, nachverfolgbaren Prozess. Starte mit einem empfohlenen Assessment, um zu sehen, wo du stehst, und nutze dann benutzerdefinierte Assessments, um Azure-Ziele zu vergleichen und deinen Migrationsplan zu erstellen.

Lies den vollständigen Walkthrough und hole dir die VS Code-Erweiterung, um es an deinem eigenen Code auszuprobieren.

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.

GitHub Copilot | The .NET Blog

Azure DevOps MCP Server April Update: WIQL-Abfragen, PAT-Auth und experimentelle MCP Apps

WIQL-Abfrageunterstützung

Personal Access Tokens

MCP-Annotationen

Wiki-Tool-Konsolidierung

Experimentell: MCP Apps

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

Copilot CLI: Sitzungen bekommen echte Namen

Schneller zwischen Sitzungen wechseln

Modell-Badges im Chat

Automatische Modellauswahl in Copilot CLI

TypeScript 7.0 Nightly Opt-in

68 Minuten täglich damit verbracht, Code neu zu erklären? Es gibt eine Lösung

Die Kontextfenster-Lüge

Die Kompaktierungssteuer

auto-memory: Eine Recall-Schicht, Kein Gedächtnissystem

Fazit

azd + GitHub Copilot: KI-gestütztes Projekt-Setup und intelligente Fehlerbehandlung

Setup mit Copilot während azd init

Was es wirklich macht

Copilot-gestützte Fehlerbehebung

Typische Fehler, bei denen das glänzt

Standardverhalten konfigurieren

Fazit

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

Autopilot-Modus merkt sich endlich deine Einstellung

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

Subagents und Agent-Teams

Terminal-Output wird automatisch mitgeliefert, wenn Agents Input senden

Die Agents-App auf macOS aktualisiert sich selbst

Die kleineren Dinge, die es wert sind zu wissen

Das Fazit

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

Was Docker Sandbox tatsächlich bietet

Warum .NET-Entwickler aufhorchen sollten

Der Sicherheitsaspekt zählt

Fazit

Agentisches Platform Engineering Wird Realität — Git-APE Zeigt Wie

Was Git-APE tatsächlich macht

Warum das wichtig ist

Meine Einschätzung

Zusammenfassung

GitHub Copilots Modernisierungs-Assessment ist das beste Migrationstool, das du noch nicht nutzt

Es ist nicht nur eine Code-Vorschlagsmaschine

Zwei Wege zum Start

Die Issue-Aufschlüsselung ist umsetzbar

Die abgedeckten Upgrade-Pfade

Meine Einschätzung

Zusammenfassung

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

Benutzerdefinierte Copilot-Agenten in deinem Repo

Agent Skills: wiederverwendbare Instruktionspakete

find_symbol: sprachbewusste Navigation

Tests mit Copilot profilen

Perf Tips beim Live-Debugging

NuGet-Schwachstellen aus dem Solution Explorer beheben

Zusammenfassung