Dotnet | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 findet vom 11. bis 15. Mai 2026 im Barbican Centre in London statt. Die 3-tägige Kernkonferenz läuft von Dienstag bis Donnerstag, mit optionalen Ganztags-Workshops am Montag und Freitag.

Mit 78 Sessions und 14 Workshops ist dies eine der umfangreichsten Entwicklerkonferenzen in Europa.

Themen

Architektonisches Denken
Funktionaler Code in C# 13
Serverless-Design
Semantische KI
Azure Kubernetes Services
Lean DevOps Strategien
The Model Context Protocol (MCP)
Agentische KI in .NET
Refactoring des Monolithen
Schneller programmieren mit LLMs
Kryptographie in einer Post-Quanten-Welt
Local-First-Entwicklung

Speaker

Weltklasse-Lineup mit Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm und Raju Gandhi.

Tickets und Infos

98 % der SDD 2025-Teilnehmer bewerteten das Gesamterlebnis als gut, sehr gut oder exzellent.

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.

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

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

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

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

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

winapp run: F5 von überall

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

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

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

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

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

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

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

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

winapp ui: UI-Automatisierung aus der Kommandozeile

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

Was möglich ist:

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

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

Weitere Neuerungen

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

Installation

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

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

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

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

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

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

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

Detached Mode: ein Befehl, Terminal zurück

aspire start

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

Laufende Prozesse verwalten

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

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

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

Kombiniere es mit dem isolierten Modus

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

aspire start --isolated
aspire start --isolated

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

Warum das für Coding-Agents riesig ist

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

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

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

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

Fazit

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

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

Pin-Clustering landet endlich in .NET MAUI Maps — Eine Property, null Aufwand

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

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

Kennst du den Moment, wenn du eine Karte mit hundert Pins lädst und das Ganze zu einem unlesbaren Klumpen wird? Ja, so war die .NET MAUI Maps-Erfahrung bisher. Damit ist jetzt Schluss.

David Ortinau hat gerade angekündigt, dass .NET MAUI 11 Preview 3 Pin-Clustering auf Android und iOS/Mac Catalyst out of the box mitliefert. Und das Beste — es ist lächerlich einfach zu aktivieren.

Eine Property, sie alle zu beherrschen

<maps:Map IsClusteringEnabled="True" />

Das war’s. Benachbarte Pins werden in Clustern mit einem Zähler-Badge gruppiert. Reinzoomen — sie expandieren. Rauszoomen — sie kollabieren. Genau das Verhalten, das Nutzer von jeder modernen Karte erwarten — und jetzt bekommst du es mit einer einzigen Property.

Unabhängige Clustering-Gruppen

Hier wird es interessant. Nicht alle Pins sollten zusammen geclustert werden. Cafés und Parks sind verschiedene Dinge, und deine Karte sollte das wissen.

Die ClusteringIdentifier-Property ermöglicht es dir, Pins in unabhängige Gruppen zu trennen:

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Pins mit demselben Identifier clustern zusammen. Verschiedene Identifier bilden unabhängige Cluster, selbst wenn sie geografisch nah beieinander liegen. Kein Identifier? Standardgruppe. Sauber und vorhersehbar.

Cluster-Taps verarbeiten

Wenn ein Nutzer auf einen Cluster tippt, bekommst du ein ClusterClicked-Event mit allem, was du brauchst:

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Die Event-Args liefern dir Pins (die Pins im Cluster), Location (das geografische Zentrum) und Handled (auf true setzen, wenn du den Standard-Zoom überschreiben willst). Einfach, praktisch, genau was man erwartet.

Plattform-Details, die man kennen sollte

Auf Android verwendet das Clustering einen eigenen Grid-basierten Algorithmus, der bei Zoom-Änderungen neu berechnet — keine externen Abhängigkeiten. Auf iOS und Mac Catalyst wird die native MKClusterAnnotation-Unterstützung von MapKit genutzt, was flüssige, plattformnative Animationen bedeutet.

Das ist einer dieser Fälle, in denen das MAUI-Team die richtige Entscheidung getroffen hat — auf die Plattform setzen, wo es Sinn ergibt.

Warum das wichtig ist

Pin-Clustering war eines der meistgewünschten Features in .NET MAUI (Issue #11811), und das aus gutem Grund. Jede App, die Standorte auf einer Karte zeigt — Lieferverfolgung, Filialfinder, Immobilien — braucht das. Vorher musstest du es selbst bauen oder eine Drittanbieter-Bibliothek einbinden. Jetzt ist es eingebaut.

Für uns .NET-Entwickler, die plattformübergreifende mobile Apps bauen, ist das genau die Art von Quality-of-Life-Verbesserung, die MAUI zu einer wirklich praktischen Wahl für kartenintensive Szenarien macht.

Loslegen

Installiere .NET 11 Preview 3 und aktualisiere den .NET MAUI Workload. Das Maps-Sample enthält eine neue Clustering-Seite, mit der du sofort loslegen kannst.

Bau etwas damit — und lass deine Karten endlich atmen.

.NET April 2026 Servicing — Sicherheitspatches, die du heute einspielen solltest

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

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

Die Servicing-Updates vom April 2026 für .NET und .NET Framework sind da, und dieses Mal sind Sicherheitsfixes dabei, die ihr zeitnah einspielen solltet. Sechs CVEs wurden gepatcht, darunter zwei Schwachstellen für Remotecodeausführung (RCE).

Was wurde gepatcht

Hier die Kurzübersicht:

CVE	Typ	Betrifft
CVE-2026-26171	Umgehung von Sicherheitsfunktionen	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Remotecodeausführung	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Remotecodeausführung	.NET 10, 9, 8
CVE-2026-32203	Denial of Service	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Denial of Service	.NET Framework 3.0–4.8.1
CVE-2026-32226	Denial of Service	.NET Framework 2.0–4.8.1

Die beiden RCE-CVEs (CVE-2026-32178 und CVE-2026-33116) betreffen die breiteste Palette an .NET-Versionen und sollten Priorität haben.

Aktualisierte Versionen

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

Alle sind über die üblichen Kanäle verfügbar — dotnet.microsoft.com, Container-Images auf MCR und Linux-Paketmanager.

Was zu tun ist

Aktualisiert eure Projekte und CI/CD-Pipelines auf die neuesten Patch-Versionen. Wenn ihr Container nutzt, zieht die neuesten Images. Wenn ihr .NET Framework einsetzt, prüft die .NET Framework Release Notes für die entsprechenden Patches.

Für alle, die .NET 10 in Produktion betreiben (es ist das aktuelle Release), ist 10.0.6 ein Pflicht-Update. Gleiches gilt für .NET 9.0.15 und .NET 8.0.26, falls ihr auf diesen LTS-Versionen seid. Zwei RCE-Schwachstellen sind nichts, was man aufschiebt.

Azure MCP Server 2.0 ist da — Self-Hosted Agentic Cloud Automation ist Realität

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

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

Falls du in letzter Zeit mit MCP und Azure etwas aufgebaut hast, weißt du wahrscheinlich schon, dass die lokale Erfahrung gut funktioniert. MCP-Server einstöpseln, deinen KI-Agenten mit Azure-Ressourcen kommunizieren lassen, weitermachen. Aber sobald du diese Einrichtung teamübergreifend teilen musst? Da wird es kompliziert.

Nicht mehr. Azure MCP Server hat gerade 2.0 Stable erreicht, und die Hauptfunktion ist genau das, wofür Enterprise-Teams gefragt haben: Self-Hosted Remote MCP Server Support.

Was ist Azure MCP Server?

Kleine Auffrischung. Azure MCP Server implementiert die Model Context Protocol-Spezifikation und macht Azure-Funktionen als strukturierte, auffindbare Tools verfügbar, die KI-Agenten aufrufen können. Denk daran als standardisierte Brücke zwischen deinem Agenten und Azure — Bereitstellung, Deployment, Monitoring, Diagnostik, alles über eine einheitliche Schnittstelle.

Die Zahlen sprechen für sich: 276 MCP Tools über 57 Azure-Dienste. Das ist umfangreiche Unterstützung.

Das Wichtigste: Self-Hosted Remote Deployments

Hier ist die Sache. MCP lokal auf deiner Maschine zu betreiben ist okay für Entwicklung und Experimente. Aber in einem echten Team-Szenario brauchst du:

Gemeinsamer Zugriff für Entwickler und interne Agent-Systeme
Zentralisierte Konfiguration (Mandantenkontext, Abonnement-Standards, Telemetrie)
Enterprise-Netzwerk- und Richtliniengrenzen
Integration in CI/CD-Pipelines

Azure MCP Server 2.0 adressiert das alles. Du kannst es als zentral verwalteten internen Service mit HTTP-basiertem Transport, ordentlicher Authentifizierung und konsistenter Governance bereitstellen.

Für die Authentifizierung hast du zwei solide Optionen:

Managed Identity — wenn neben Microsoft Foundry betrieben
On-Behalf-Of (OBO) Flow — OpenID Connect Delegation, die Azure APIs mit dem Kontext des angemeldeten Benutzers aufruft

Dieser OBO-Flow ist besonders interessant für uns .NET-Entwickler. Das bedeutet, dass deine Agentic Workflows mit den eigentlichen Berechtigungen des Benutzers arbeiten können, nicht mit einem überberechtigten Service-Account. Principle of Least Privilege, gleich eingebaut.

Security Hardening

Das ist nicht nur ein Feature-Release — es ist auch eines für Sicherheit. Das 2.0-Release fügt hinzu:

Stärkere Endpoint-Validierung
Schutz gegen Injection-Muster in Query-orientierten Tools
Strengere Isolationskontrollen für Dev-Umgebungen

Falls du MCP als gemeinsamen Service bereitstellen willst, zählen diese Schutzmaßnahmen. Eine Menge.

Wo kannst du es verwenden?

Die Client-Kompatibilität ist breit. Azure MCP Server 2.0 funktioniert mit:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI Agents: GitHub Copilot CLI, Claude Code
Standalone: lokaler Server für einfache Setups
Self-Hosted Remote: der neue Star von 2.0

Zusätzlich gibt es Sovereign Cloud Support für Azure US Government und Azure von 21Vianet betrieben, was für regulierte Deployments entscheidend ist.

Warum das für .NET-Entwickler wichtig ist

Falls du Agentic Anwendungen mit .NET aufbaust — ob das Semantic Kernel, Microsoft Agent Framework oder deine eigene Orchestrierung ist — gibt dir Azure MCP Server 2.0 eine produktionsreife Möglichkeit, deinen Agenten mit Azure-Infrastruktur zu interagieren. Keine benutzerdefinierten REST-Wrapper. Keine Service-spezifischen Integrationsmuster. Einfach MCP.

Kombiniert mit der Fluent API für MCP Apps, die vor ein paar Tagen kam, reift das .NET MCP-Ökosystem schnell.

Erste Schritte

Wähle deinen Weg:

GitHub Repo — Quellcode, Docs, alles
Docker Image — containerisiertes Deployment
VS Code Extension — IDE-Integration
Self-Hosting Guide — das Flaggschiff-Feature von 2.0

Zusammenfassung

Azure MCP Server 2.0 ist genau die Art von Infrastruktur-Upgrade, das in einer Demo nicht glamourös aussieht, aber in der Praxis alles verändert. Self-Hosted Remote MCP mit ordnungsgemäßer Authentifizierung, Security Hardening und Sovereign Cloud Support bedeutet, dass MCP bereit für echte Teams ist, die echte Agentic Workflows auf Azure aufbauen. Falls du auf das „Enterprise-Ready"-Signal gewartet hast — das ist es.

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

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.

MCP Apps bekommen eine Fluent API — Erstelle reichhaltige AI-Tool-UIs in .NET in drei Schritten

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

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

MCP-Tools sind großartig, um AI-Agenten Fähigkeiten zu geben. Aber was, wenn dein Tool dem Benutzer etwas zeigen muss — ein Dashboard, ein Formular, eine interaktive Visualisierung? Genau dafür gibt es MCP Apps, und sie sind jetzt viel einfacher zu erstellen.

Lilian Kasem vom Azure SDK-Team hat die neue Fluent-Konfigurations-API vorgestellt für MCP Apps auf .NET Azure Functions, und es ist die Art von Verbesserung der Entwicklererfahrung, bei der man sich fragt, warum es nicht schon immer so einfach war.

Was sind MCP Apps?

MCP Apps erweitern das Model Context Protocol, indem sie Tools eigene UI-Views, statische Assets und Sicherheitskontrollen mitgeben können. Anstatt nur Text zurückzugeben, kann dein MCP-Tool vollständige HTML-Erlebnisse rendern — interaktive Dashboards, Datenvisualisierungen, Konfigurationsformulare — alles von AI-Agenten aufrufbar und den Benutzern durch MCP-Clients präsentiert.

Der Haken war, dass das manuelle Verkabeln all dieser Dinge tiefes Wissen über die MCP-Spezifikation erforderte: ui://-URIs, spezielle MIME-Types, Metadaten-Koordination zwischen Tools und Ressourcen. Nicht schwer, aber fummellig.

Die Fluent API in drei Schritten

Schritt 1: Definiere deine Funktion. Ein standardmäßiges Azure Functions MCP-Tool:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Schritt 2: Mach sie zur MCP App. In deinem Programm-Startup:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Schritt 3: Füge deine HTML-View hinzu. Erstelle assets/hello-app.html mit der UI, die du brauchst.

Das war’s. Die Fluent API kümmert sich um die gesamte MCP-Protokoll-Plumbing — generiert die synthetische Ressourcen-Funktion, setzt den korrekten MIME-Type und injiziert die Metadaten, die dein Tool mit seiner View verbinden.

Die API-Oberfläche ist gut durchdacht

Ein paar Dinge, die mir besonders gefallen:

View-Quellen sind flexibel. Du kannst HTML von Dateien auf der Festplatte servieren oder Ressourcen direkt in deine Assembly einbetten für eigenständige Deployments:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP ist komponierbar. Du erlaubst explizit die Origins, die deine App braucht, nach dem Prinzip der minimalen Berechtigung. Rufe WithCsp mehrmals auf und die Origins akkumulieren sich:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Sichtbarkeitskontrolle. Du kannst ein Tool nur für das LLM sichtbar machen, nur für die Host-UI oder für beides. Du willst ein Tool, das nur UI rendert und nicht vom Modell aufgerufen werden soll? Kein Problem:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Erste Schritte

Füge das Preview-Paket hinzu:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Wenn du bereits MCP-Tools mit Azure Functions baust, ist das nur ein Paket-Update. Der MCP Apps Quickstart ist der beste Einstiegspunkt, wenn du neu im Konzept bist.

Zusammenfassung

MCP Apps sind eine der spannendsten Entwicklungen im AI-Tooling-Bereich — Tools, die nicht nur Dinge tun, sondern den Benutzern auch Dinge zeigen können. Die Fluent API entfernt die Protokollkomplexität und lässt dich auf das Wesentliche konzentrieren: die Logik deines Tools und seine Oberfläche.

Lies den vollständigen Beitrag für die komplette API-Referenz und Beispiele.

Verbinde deine MCP-Server auf Azure Functions mit Foundry Agents — So geht's

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

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

Das liebe ich am MCP-Ökosystem: Du baust deinen Server einmal, und er funktioniert überall. VS Code, Visual Studio, Cursor, ChatGPT — jeder MCP-Client kann deine Tools entdecken und nutzen. Jetzt fügt Microsoft einen weiteren Konsumenten zu dieser Liste hinzu: Foundry-Agenten.

Lily Ma vom Azure SDK-Team hat einen praktischen Leitfaden veröffentlicht zur Verbindung von MCP-Servern auf Azure Functions mit Microsoft Foundry-Agenten. Wenn du bereits einen MCP-Server hast, ist das reiner Mehrwert — kein Neuaufbau nötig.

Warum diese Kombination Sinn macht

Azure Functions bietet dir skalierbare Infrastruktur, integrierte Authentifizierung und Serverless-Abrechnung für das Hosting von MCP-Servern. Microsoft Foundry bietet dir AI-Agenten, die denken, planen und handeln können. Beides zu verbinden bedeutet, dass deine benutzerdefinierten Tools — Datenbankabfragen, Business-API-Aufrufe, Validierungslogik — zu Fähigkeiten werden, die Enterprise-AI-Agenten autonom entdecken und nutzen können.

Der Kernpunkt: Dein MCP-Server bleibt gleich. Du fügst einfach Foundry als weiteren Konsumenten hinzu. Die gleichen Tools, die in deinem VS Code-Setup funktionieren, treiben jetzt einen AI-Agenten an, mit dem dein Team oder deine Kunden interagieren.

Authentifizierungsoptionen

Hier liefert der Post echten Mehrwert. Vier Authentifizierungsmethoden je nach Szenario:

Methode	Anwendungsfall
Schlüsselbasiert (Standard)	Entwicklung oder Server ohne Entra-Auth
Microsoft Entra	Produktion mit verwalteten Identitäten
OAuth Identity Passthrough	Produktion, bei der sich jeder Benutzer einzeln authentifiziert
Ohne Authentifizierung	Entwicklung/Tests oder nur öffentliche Daten

Für die Produktion ist Microsoft Entra mit Agentenidentität der empfohlene Weg. OAuth Identity Passthrough ist für Fälle, in denen der Benutzerkontext wichtig ist — der Agent fordert Benutzer zur Anmeldung auf, und jede Anfrage trägt das eigene Token des Benutzers.

Einrichtung

Der allgemeine Ablauf:

Deploye deinen MCP-Server auf Azure Functions — Beispiele verfügbar für .NET, Python, TypeScript und Java
Aktiviere die integrierte MCP-Authentifizierung auf deiner Function App
Hole deine Endpoint-URL — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Füge den MCP-Server als Tool in Foundry hinzu — navigiere zu deinem Agenten im Portal, füge ein neues MCP-Tool hinzu, gib Endpoint und Credentials an

Dann teste es im Agent Builder Playground, indem du einen Prompt sendest, der eines deiner Tools auslöst.

Meine Einschätzung

Die Composability-Geschichte wird hier richtig stark. Baue deinen MCP-Server einmal in .NET (oder Python, TypeScript, Java), deploye ihn auf Azure Functions, und jeder MCP-kompatible Client kann ihn nutzen — Coding-Tools, Chat-Apps und jetzt Enterprise-AI-Agenten. Das ist ein „einmal schreiben, überall nutzen"-Muster, das tatsächlich funktioniert.

Speziell für .NET-Entwickler macht die Azure Functions MCP-Erweiterung das unkompliziert. Du definierst deine Tools als Azure Functions, deployest sie, und du hast einen produktionsreifen MCP-Server mit der gesamten Sicherheit und Skalierung, die Azure Functions bietet.

Zusammenfassung

Wenn du MCP-Tools auf Azure Functions betreibst, ist die Verbindung mit Foundry-Agenten ein schneller Gewinn — deine benutzerdefinierten Tools werden zu Enterprise-AI-Fähigkeiten mit korrekter Authentifizierung und ohne Code-Änderungen am Server selbst.

Lies den vollständigen Leitfaden für Schritt-für-Schritt-Anleitungen zu jeder Authentifizierungsmethode, und sieh dir die detaillierte Dokumentation für Produktions-Setups an.

C# 15 bekommt Union Types — und sie sind genau das, was wir uns gewünscht haben

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

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

Das ist das Feature, auf das ich gewartet habe. C# 15 führt das union-Schlüsselwort ein — echte diskriminierte Unions mit compiler-erzwungenem erschöpfendem Pattern Matching. Wenn du jemals die diskriminierten Unions von F# oder die Enums von Rust beneidet hast, weißt du genau, warum das wichtig ist.

Bill Wagner hat den Deep Dive veröffentlicht auf dem .NET Blog, und ehrlich? Das Design ist sauber, praktisch und sehr C#. Lass mich dir zeigen, was wirklich hier ist und warum es eine größere Sache ist, als es auf den ersten Blick scheint.

Das Problem, das Unions lösen

Vor C# 15 war die Rückgabe von “einem von mehreren möglichen Typen” aus einer Methode immer ein Kompromiss:

object — keine Einschränkungen, keine Compiler-Hilfe, defensives Casting überall
Marker-Interfaces — besser, aber jeder kann sie implementieren. Der Compiler kann die Menge nie als vollständig betrachten
Abstrakte Basisklassen — gleiches Problem, plus die Typen brauchen einen gemeinsamen Vorfahren

Nichts davon gibt dir, was du eigentlich willst: eine geschlossene Menge von Typen, bei der der Compiler garantiert, dass du jeden Fall behandelt hast. Das ist es, was Union Types machen.

Die Syntax ist wunderschön einfach

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Eine Zeile. Pet kann eine Cat, einen Dog oder einen Bird enthalten. Implizite Konvertierungen werden automatisch generiert:

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

Und hier ist die Magie — der Compiler erzwingt erschöpfendes Matching:

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

Kein Discard _ nötig. Der Compiler weiß, dass dieser Switch jeden möglichen Fall abdeckt. Wenn du später einen vierten Typ zur Union hinzufügst, erzeugt jeder Switch-Ausdruck, der ihn nicht behandelt, eine Warnung. Fehlende Fälle werden zur Build-Zeit erkannt, nicht zur Laufzeit.

Wo das praktisch wird

Das Pet-Beispiel ist nett, aber hier glänzen Unions wirklich in echtem Code.

API-Antworten, die verschiedene Formen zurückgeben

public union ApiResult<T>(T, ApiError, ValidationFailure);

Jetzt ist jeder Konsument gezwungen, Erfolg, Fehler und Validierungsfehler zu behandeln. Keine “Ich habe vergessen, den Fehlerfall zu prüfen”-Bugs mehr.

Einzelwert oder Collection

Das OneOrMore<T>-Muster zeigt, wie Unions einen Body mit Hilfsmethoden haben können:

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Aufrufer übergeben die Form, die ihnen passt:

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Unrelated Typen zusammensetzen

Das ist das Killer-Feature gegenüber traditionellen Hierarchien. Du kannst Typen vereinen, die nichts gemeinsam haben — string und Exception, int und IEnumerable<T>. Kein gemeinsamer Vorfahre nötig.

Custom Unions für bestehende Bibliotheken

Hier ist eine clevere Design-Entscheidung: Jede Klasse oder Struct mit einem [Union]-Attribut wird als Union-Typ erkannt, solange sie dem grundlegenden Muster folgt (öffentliche Konstruktoren für Case-Typen und eine Value-Property). Bibliotheken wie OneOf, die bereits Union-ähnliche Typen bereitstellen, können sich für Compiler-Unterstützung entscheiden, ohne ihre Interna umzuschreiben.

Für performance-sensitive Szenarien mit Werttypen können Bibliotheken ein Boxing-freies Zugriffsmuster mit HasValue- und TryGetValue-Methoden implementieren.

Das große Ganze

Union Types sind Teil einer breiteren Exhaustiveness-Story, die zu C# kommt:

Union Types — erschöpfendes Matching über eine geschlossene Menge von Typen (jetzt in Preview verfügbar)
Geschlossene Hierarchien — der closed-Modifier verhindert abgeleitete Klassen außerhalb der definierenden Assembly (vorgeschlagen)
Geschlossene Enums — verhindert die Erstellung von Werten außer den deklarierten Membern (vorgeschlagen)

Zusammen werden diese drei Features C# eines der umfassendsten typsicheren Pattern-Matching-Systeme in jeder Mainstream-Sprache geben.

Probier es heute aus

Union Types sind in .NET 11 Preview 2 verfügbar:

Installiere das .NET 11 Preview SDK
Setze net11.0 als Target in deinem Projekt
Setze <LangVersion>preview</LangVersion>

Ein Hinweis: In Preview 2 musst du UnionAttribute und IUnion in deinem Projekt deklarieren, da sie noch nicht in der Runtime sind. Hol dir RuntimePolyfill.cs aus dem Docs-Repo, oder füge das hinzu:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Fazit

Union Types sind eines dieser Features, bei denen man sich fragt, wie wir ohne sie ausgekommen sind. Compiler-erzwungenes erschöpfendes Matching, saubere Syntax, generische Unterstützung und Integration mit bestehendem Pattern Matching — es ist alles, was wir wollten, auf die C#-Art umgesetzt.

Probier sie in .NET 11 Preview 2 aus, mach Sachen kaputt und teile dein Feedback auf GitHub. Das ist Preview, und das C#-Team hört aktiv zu. Deine Edge Cases und Design-Feedback werden die finale Version formen.

Für die vollständige Sprachreferenz, schau dir die Union Types-Dokumentation und die Feature-Spezifikation 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.

Microsoft Agent Framework Erreicht 1.0 — Das Ist Wirklich Wichtig für .NET-Entwickler

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

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

Wenn du die Reise des Agent Frameworks seit den frühen Tagen von Semantic Kernel und AutoGen verfolgt hast, ist das hier bedeutend. Microsoft Agent Framework hat gerade Version 1.0 erreicht — produktionsreif, stabile APIs, langfristiges Support-Commitment. Es ist sowohl für .NET als auch für Python verfügbar und wirklich bereit für echte Workloads.

Ich schneide durch den Ankündigungslärm und konzentriere mich auf das, was wichtig ist, wenn du KI-gestützte Apps mit .NET baust.

Die Kurzversion

Agent Framework 1.0 vereint das, was früher Semantic Kernel und AutoGen waren, in ein einziges Open-Source-SDK. Eine Agent-Abstraktion. Eine Orchestrierungs-Engine. Mehrere KI-Anbieter. Wenn du zwischen Semantic Kernel für Enterprise-Patterns und AutoGen für forschungsbasierte Multi-Agent-Workflows hin und her gesprungen bist, kannst du aufhören. Das ist jetzt das eine SDK.

Der Einstieg ist fast unfair einfach

Hier ist ein funktionierender Agent in .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Das war’s. Eine Handvoll Zeilen und du hast einen KI-Agenten, der gegen Azure Foundry läuft. Das Python-Äquivalent ist genauso knapp. Füge Funktions-Tools, Multi-Turn-Konversationen und Streaming hinzu, wie du vorankommst — die API-Oberfläche skaliert, ohne seltsam zu werden.

Multi-Agent-Orchestrierung — das ist die echte Sache

Einzelne Agenten sind gut für Demos, aber Produktionsszenarien brauchen normalerweise Koordination. Agent Framework 1.0 liefert kampferprobte Orchestrierungsmuster direkt von Microsoft Research und AutoGen:

Sequenziell — Agenten verarbeiten der Reihe nach (Autor → Reviewer → Editor)
Gleichzeitig — verteile an mehrere Agenten parallel, führe Ergebnisse zusammen
Handoff — ein Agent delegiert basierend auf der Absicht an einen anderen
Gruppen-Chat — mehrere Agenten diskutieren und konvergieren zu einer Lösung
Magentic-One — das forschungsbasierte Multi-Agent-Pattern von MSR

Alle unterstützen Streaming, Checkpointing, Human-in-the-Loop-Freigaben und Pause/Fortsetzen. Der Checkpointing-Teil ist entscheidend — lang laufende Workflows überleben Prozess-Neustarts. Für uns .NET-Entwickler, die dauerhafte Workflows mit Azure Functions gebaut haben, fühlt sich das vertraut an.

Die Features, die am meisten zählen

Hier ist meine Shortlist dessen, was wissenswert ist:

Middleware-Hooks. Du weißt, wie ASP.NET Core Middleware-Pipelines hat? Gleiches Konzept, aber für die Agent-Ausführung. Fange jede Stufe ab — füge Content-Sicherheit, Logging, Compliance-Richtlinien hinzu — ohne die Agent-Prompts anzufassen. So machst du Agenten enterprise-ready.

Steckbare Memory. Konversationshistorie, persistenter Key-Value-State, vektorbasiertes Retrieval. Wähle dein Backend: Foundry Agent Service, Mem0, Redis, Neo4j, oder baue dein eigenes. Memory ist das, was einen zustandslosen LLM-Aufruf in einen Agenten verwandelt, der sich tatsächlich an den Kontext erinnert.

Deklarative YAML-Agenten. Definiere die Anweisungen, Tools, Memory und Orchestrierungs-Topologie deines Agenten in versionskontrollierten YAML-Dateien. Lade und starte mit einem einzigen API-Aufruf. Das ist ein Game-Changer für Teams, die das Agent-Verhalten iterieren wollen, ohne Code neu zu deployen.

A2A- und MCP-Unterstützung. MCP (Model Context Protocol) ermöglicht es Agenten, externe Tools dynamisch zu entdecken und aufzurufen. A2A (Agent-to-Agent-Protokoll) ermöglicht runtime-übergreifende Zusammenarbeit — deine .NET-Agenten können sich mit Agenten in anderen Frameworks koordinieren. A2A 1.0-Unterstützung kommt bald.

Die Preview-Features, die es wert sind, beobachtet zu werden

Einige Features wurden als Preview in 1.0 ausgeliefert — funktional, aber APIs können sich weiterentwickeln:

DevUI — ein browserbasierter lokaler Debugger zur Visualisierung der Agent-Ausführung, Nachrichtenflüsse und Tool-Aufrufe in Echtzeit. Denk an Application Insights, aber für Agent-Reasoning.
GitHub Copilot SDK und Claude Code SDK — verwende Copilot oder Claude als Agent-Harness direkt aus deinem Orchestrierungscode. Komponiere einen programmierfähigen Agenten neben deinen anderen Agenten im selben Workflow.
Agent Harness — eine anpassbare lokale Runtime, die Agenten Zugriff auf Shell, Dateisystem und Messaging-Loops gibt. Denk an Coding-Agenten und Automatisierungsmuster.
Skills — wiederverwendbare Domain-Capability-Pakete, die Agenten strukturierte Fähigkeiten out of the box geben.

Migration von Semantic Kernel oder AutoGen

Wenn du bestehenden Semantic Kernel- oder AutoGen-Code hast, gibt es dedizierte Migrationsassistenten, die deinen Code analysieren und schrittweise Migrationspläne generieren. Der Semantic Kernel Migrationsleitfaden und der AutoGen Migrationsleitfaden führen dich durch alles.

Wenn du auf den RC-Paketen warst, ist das Upgrade auf 1.0 nur ein Versions-Bump.

Zum Abschluss

Agent Framework 1.0 ist der Produktions-Meilenstein, auf den Enterprise-Teams gewartet haben. Stabile APIs, Multi-Provider-Support, Orchestrierungsmuster, die tatsächlich im großen Maßstab funktionieren, und Migrationspfade von sowohl Semantic Kernel als auch AutoGen.

Das Framework ist vollständig Open Source auf GitHub, und du kannst heute mit dotnet add package Microsoft.Agents.AI loslegen. Schau dir den Schnellstart-Leitfaden und die Beispiele an, um praktisch einzusteigen.

Wenn du auf das Signal „sicher für den Produktionseinsatz" gewartet hast — das ist es.

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.

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

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

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

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

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

Telemetrie exportieren wie ein normaler Mensch

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

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

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

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

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

Die Telemetrie-API ist der echte Game Changer

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

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

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

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

GenAI-Telemetrie wird praktisch

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

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

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

Zusammenfassung

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

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

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.

KubeCon Europe 2026: Was .NET-Entwickler wirklich wissen sollten

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

Kennst du das Gefühl, wenn ein riesiger Ankündigungs-Post erscheint und du durchscrollst und denkst: „Cool, aber was ändert das jetzt tatsächlich für mich"? So geht es mir jede KubeCon-Saison.

Microsoft hat gerade ihren vollständigen KubeCon Europe 2026 Überblick veröffentlicht — geschrieben von Brendan Burns persönlich — und ehrlich gesagt steckt hier echte Substanz drin. Nicht nur Feature-Checklisten, sondern operative Verbesserungen, die ändern, wie du Dinge in Produktion betreibst.

Lass mich aufschlüsseln, was für uns .NET-Entwickler wirklich zählt.

mTLS ohne die Service-Mesh-Steuer

Hier ist die Sache mit Service Meshes: Jeder will die Sicherheitsgarantien, niemand will den operativen Overhead. AKS schließt diese Lücke endlich.

Azure Kubernetes Application Network gibt dir Mutual TLS, anwendungsbewusste Autorisierung und Traffic-Telemetrie — ohne ein volles Sidecar-lastiges Mesh zu deployen. In Kombination mit Cilium mTLS in Advanced Container Networking Services bekommst du verschlüsselte Pod-zu-Pod-Kommunikation mit X.509-Zertifikaten und SPIRE für Identity Management.

Was das in der Praxis bedeutet: Deine ASP.NET Core APIs, die mit Background-Workern kommunizieren, deine gRPC-Services, die sich gegenseitig aufrufen — alles verschlüsselt und identitätsverifiziert auf Netzwerkebene, ohne eine einzige Code-Änderung. Das ist gewaltig.

Für Teams, die von ingress-nginx migrieren, gibt es außerdem Application Routing mit Meshless Istio mit vollem Kubernetes Gateway API Support. Keine Sidecars. Standardbasiert. Und sie haben ingress2gateway-Tools für inkrementelle Migration mitgeliefert.

GPU-Observability, die kein Nachgedanke ist

Wenn du KI-Inferenz neben deinen .NET-Services ausführst (und seien wir ehrlich, wer fängt nicht langsam damit an?), bist du wahrscheinlich auf den GPU-Monitoring-Blindspot gestoßen. Du hattest großartige CPU/Memory-Dashboards und dann… nichts für GPUs ohne manuelle Exporter-Konfiguration.

AKS zeigt GPU-Metriken jetzt nativ in Managed Prometheus und Grafana an. Gleicher Stack, gleiche Dashboards, gleiche Alerting-Pipeline. Keine Custom-Exporter, keine Third-Party-Agents.

Auf der Netzwerkseite wurde Per-Flow-Visibilität für HTTP-, gRPC- und Kafka-Traffic mit einer One-Click Azure Monitor-Erfahrung hinzugefügt. IPs, Ports, Workloads, Flow-Richtung, Policy-Entscheidungen — alles in eingebauten Dashboards.

Und hier kommt die, bei der ich zweimal hingeschaut habe: Agentic Container Networking fügt eine Web-UI hinzu, in der du natürlichsprachliche Fragen zum Netzwerkzustand deines Clusters stellen kannst. „Warum erreicht Pod X Service Y nicht?" → Read-Only-Diagnose aus Live-Telemetrie. Das ist um 2 Uhr nachts wirklich nützlich.

Cross-Cluster-Networking ohne Doktortitel

Multi-Cluster Kubernetes war historisch eine „Bring deinen eigenen Netzwerk-Kleber mit"-Erfahrung. Azure Kubernetes Fleet Manager liefert jetzt Cross-Cluster-Networking über Managed Cilium Cluster Mesh:

Einheitliche Konnektivität über AKS-Cluster hinweg
Globale Service-Registry für Cross-Cluster-Discovery
Zentral verwaltete Konfiguration statt pro Cluster wiederholt

Wenn du .NET-Microservices über Regionen hinweg für Resilienz oder Compliance betreibst, ersetzt das eine Menge fragilen Custom-Kleber. Service A in West Europe kann Service B in East US über das Mesh entdecken und aufrufen, mit konsistenten Routing- und Sicherheitsrichtlinien.

Upgrades, die keinen Mut erfordern

Seien wir ehrlich — Kubernetes-Upgrades in Produktion sind stressig. „Upgraden und hoffen" war die De-facto-Strategie für zu viele Teams und der Hauptgrund, warum Cluster bei Versionen hinterherhinken.

Zwei neue Fähigkeiten ändern das:

Blue-Green Agent Pool Upgrades erstellen einen parallelen Node-Pool mit der neuen Konfiguration. Verhalten validieren, Traffic schrittweise verlagern und einen sauberen Rollback-Pfad behalten. Keine In-Place-Mutationen auf Produktions-Nodes mehr.

Agent Pool Rollback ermöglicht es, einen Node-Pool auf seine vorherige Kubernetes-Version und Node-Image zurückzusetzen, wenn ein Upgrade schiefgeht — ohne den Cluster neu aufzubauen.

Zusammen geben sie Operatoren endlich echte Kontrolle über den Upgrade-Lebenszyklus. Für .NET-Teams ist das wichtig, weil Plattform-Geschwindigkeit direkt steuert, wie schnell du neue Runtimes, Sicherheitspatches und Netzwerk-Fähigkeiten einsetzen kannst.

KI-Workloads werden zu First-Class Kubernetes-Bürgern

Die Upstream-Open-Source-Arbeit ist gleichermaßen wichtig. Dynamic Resource Allocation (DRA) ist gerade in Kubernetes 1.36 GA geworden und macht GPU-Scheduling zu einem echten First-Class-Feature statt eines Workarounds.

Einige Projekte, die es wert sind beobachtet zu werden:

Projekt	Was es macht
AI Runway	Gemeinsame Kubernetes-API für Inferenz — Models deployen ohne K8s-Kenntnisse, mit HuggingFace-Discovery und Kostenschätzungen
HolmesGPT	Agentisches Troubleshooting für Cloud-Native — jetzt ein CNCF-Sandbox-Projekt
Dalec	Deklarative Container-Image-Builds mit SBOM-Generierung — weniger CVEs in der Build-Phase

Die Richtung ist klar: Deine .NET-API, deine Semantic-Kernel-Orchestrierungsschicht und deine Inferenz-Workloads sollten alle auf einem konsistenten Plattformmodell laufen. Wir kommen dahin.

Wo ich diese Woche anfangen würde

Wenn du diese Änderungen für dein Team evaluierst, hier meine ehrliche Prioritätenliste:

Observability zuerst — GPU-Metriken und Netzwerk-Flow-Logs in einem Nicht-Prod-Cluster aktivieren. Schau dir an, was du verpasst hast.
Blue-Green-Upgrades testen — den Rollback-Workflow vor deinem nächsten Produktions-Cluster-Upgrade ausprobieren. Vertrauen in den Prozess aufbauen.
Identity-Aware Networking pilotieren — einen internen Service-Pfad wählen und mTLS mit Cilium aktivieren. Den Overhead messen (Spoiler: er ist minimal).
Fleet Manager evaluieren — wenn du mehr als zwei Cluster betreibst, zahlt sich Cross-Cluster-Networking durch weniger Custom-Kleber von selbst.

Kleine Experimente, schnelles Feedback. Das ist immer der richtige Zug.

Zum Schluss

KubeCon-Ankündigungen können überwältigend sein, aber diese Runde bewegt wirklich etwas für .NET-Teams auf AKS. Bessere Netzwerksicherheit ohne Mesh-Overhead, echte GPU-Observability, sicherere Upgrades und stärkere KI-Infrastruktur-Grundlagen.

Wenn du bereits auf AKS bist, ist jetzt ein großartiger Moment, deine operative Baseline zu verbessern. Und wenn du planst, .NET-Workloads auf Kubernetes zu verlagern — die Plattform ist gerade deutlich produktionsreifer geworden.

Background Responses im Microsoft Agent Framework: Keine Timeout-Angst mehr

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

Wenn du irgendetwas mit Reasoning-Modellen wie o3 oder GPT-5.2 gebaut hast, kennst du den Schmerz. Dein Agent fängt an, über eine komplexe Aufgabe nachzudenken, der Client wartet, und irgendwo zwischen “das ist okay” und “ist das abgestürzt?” bricht deine Verbindung wegen Timeout ab. Die ganze Arbeit? Weg.

Das Microsoft Agent Framework hat gerade Background Responses ausgeliefert — und ehrlich gesagt, das ist eine dieser Funktionen, die von Anfang an hätte existieren sollen.

Das Problem mit blockierenden Aufrufen

In einem traditionellen Request-Response-Muster blockiert dein Client, bis der Agent fertig ist. Das funktioniert gut für schnelle Aufgaben. Aber wenn du ein Reasoning-Modell bittest, tiefgehende Recherche, mehrstufige Analyse oder einen 20-seitigen Bericht zu erstellen? Da schaust du auf Minuten realer Wartezeit. Während dieses Zeitfensters:

HTTP-Verbindungen können ablaufen
Netzwerkunterbrechungen zerstören die gesamte Operation
Dein Benutzer starrt auf einen Spinner und fragt sich, ob irgendetwas passiert

Background Responses drehen das Ganze um.

Wie Continuation Tokens funktionieren

Anstatt zu blockieren, startest du die Agent-Aufgabe und bekommst ein Continuation Token zurück. Denk daran wie an einen Abholschein in einer Werkstatt — du stehst nicht an der Theke und wartest, du kommst zurück, wenn es fertig ist.

Der Ablauf ist unkompliziert:

Sende deine Anfrage mit AllowBackgroundResponses = true
Wenn der Agent Hintergrundverarbeitung unterstützt, bekommst du ein Continuation Token
Polle nach deinem Zeitplan, bis das Token null zurückgibt — das bedeutet, das Ergebnis ist fertig

Hier ist die .NET-Version:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Pollen bis fertig
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Wenn der Agent sofort fertig wird (einfache Aufgaben, Modelle die keine Hintergrundverarbeitung brauchen), wird kein Continuation Token zurückgegeben. Dein Code funktioniert einfach — keine spezielle Behandlung nötig.

Streaming mit Wiederaufnahme: die echte Magie

Polling ist gut für Fire-and-Forget-Szenarien, aber was, wenn du Echtzeit-Fortschritt willst? Background Responses unterstützen auch Streaming mit eingebauter Wiederaufnahme.

Jedes gestreamte Update trägt sein eigenes Continuation Token. Wenn deine Verbindung mitten im Stream abbricht, setzt du genau dort fort, wo du aufgehört hast:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simuliere eine Netzwerkunterbrechung
}

// Genau dort fortsetzen, wo wir aufgehört haben
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Der Agent verarbeitet serverseitig weiter, unabhängig davon, was mit deinem Client passiert. Das ist eingebaute Fehlertoleranz, ohne dass du Retry-Logik oder Circuit Breaker schreiben musst.

Wann man das tatsächlich verwenden sollte

Nicht jeder Agent-Aufruf braucht Background Responses. Für schnelle Completions fügst du Komplexität ohne Grund hinzu. Aber hier glänzen sie:

Komplexe Reasoning-Aufgaben — mehrstufige Analyse, tiefgehende Recherche, alles was ein Reasoning-Modell wirklich zum Nachdenken bringt
Lange Content-Generierung — detaillierte Berichte, mehrteilige Dokumente, ausführliche Analysen
Unzuverlässige Netzwerke — mobile Clients, Edge-Deployments, instabile Firmen-VPNs
Asynchrone UX-Muster — Aufgabe absenden, etwas anderes machen, Ergebnisse abholen

Für uns .NET-Entwickler, die Enterprise-Apps bauen, ist der letzte Punkt besonders interessant. Denk an eine Blazor-App, in der ein Benutzer einen komplexen Bericht anfordert — du startest die Agent-Aufgabe, zeigst einen Fortschrittsindikator und lässt sie weiterarbeiten. Keine WebSocket-Akrobatik, keine selbstgebaute Queue-Infrastruktur, nur ein Token und eine Poll-Schleife.

Zusammenfassung

Background Responses sind jetzt sowohl in .NET als auch in Python über das Microsoft Agent Framework verfügbar. Wenn du Agenten baust, die mehr als einfaches Q&A machen, lohnt es sich, das in dein Toolkit aufzunehmen. Das Continuation-Token-Muster hält die Dinge einfach und löst gleichzeitig ein sehr reales Produktionsproblem.

Schau dir die vollständige Dokumentation für die komplette API-Referenz und weitere Beispiele an.

Foundry Agent Service ist GA: Was für .NET-Agent-Entwickler wirklich zählt

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

Seien wir ehrlich — einen KI-Agenten-Prototyp zu bauen ist der einfache Teil. Der schwierige Teil ist alles danach: ihn in Produktion zu bringen mit ordentlicher Netzwerk-Isolation, Evaluierungen durchzuführen die wirklich etwas bedeuten, Compliance-Anforderungen zu erfüllen und um 2 Uhr morgens nichts kaputt zu machen.

Der Foundry Agent Service ist jetzt GA, und dieses Release ist laser-fokussiert auf genau diese “alles danach”-Lücke.

Gebaut auf der Responses API

Die Schlagzeile: der Foundry Agent Service der nächsten Generation basiert auf der OpenAI Responses API. Wenn du bereits mit diesem Wire-Protokoll baust, erfordert die Migration zu Foundry minimale Code-Änderungen. Was du gewinnst: Enterprise-Sicherheit, Private Networking, Entra RBAC, vollständiges Tracing und Evaluierung — auf deiner bestehenden Agent-Logik.

Die Architektur ist bewusst offen. Du bist nicht an einen Modell-Anbieter oder ein Orchestrierungs-Framework gebunden. Nutze DeepSeek fürs Planen, OpenAI für die Generierung, LangGraph für die Orchestrierung — die Runtime kümmert sich um die Konsistenz-Schicht.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Wenn du vom azure-ai-agents-Paket kommst: Agenten sind jetzt First-Class-Operationen auf AIProjectClient in azure-ai-projects. Entferne die standalone-Abhängigkeit und nutze get_openai_client() um Responses zu steuern.

Private Networking: der Enterprise-Blocker beseitigt

Das ist die Funktion, die Enterprise-Adoption freischaltet. Foundry unterstützt jetzt vollständiges End-to-End Private Networking mit BYO VNet:

Kein öffentlicher Egress — Agent-Traffic berührt nie das öffentliche Internet
Container/Subnet-Injection in dein Netzwerk für lokale Kommunikation
Tool-Konnektivität inklusive — MCP-Server, Azure AI Search, Fabric-Datenagenten operieren alle über private Pfade

Der letzte Punkt ist entscheidend. Es sind nicht nur Inferenz-Aufrufe, die privat bleiben — jeder Tool-Aufruf und jede Retrieval-Anfrage bleibt ebenfalls innerhalb deiner Netzwerk-Grenze. Für Teams, die unter Datenklassifizierungsrichtlinien arbeiten, die externes Routing verbieten, war das was fehlte.

MCP-Authentifizierung richtig gemacht

MCP-Server-Verbindungen unterstützen jetzt das volle Spektrum an Auth-Patterns:

Auth-Methode	Wann verwenden
Key-basiert	Einfacher geteilter Zugriff für org-weite interne Tools
Entra Agent Identity	Service-to-Service; der Agent authentifiziert sich als er selbst
Entra Managed Identity	Projekt-Isolation; kein Credential-Management
OAuth Identity Passthrough	Benutzer-delegierter Zugriff; Agent handelt im Auftrag der Benutzer

OAuth Identity Passthrough ist der interessante. Wenn Benutzer einem Agenten Zugriff auf ihre persönlichen Daten geben müssen — ihr OneDrive, ihre Salesforce-Org, eine SaaS-API mit Benutzer-Scope — handelt der Agent in ihrem Auftrag mit Standard-OAuth-Flows. Keine geteilte System-Identität, die vorgibt, alle zu sein.

Voice Live: Sprache-zu-Sprache ohne das Leitungswirrwarr

Einem Agenten Sprache hinzuzufügen bedeutete bisher, STT, LLM und TTS zusammenzufügen — drei Services, drei Latenz-Hops, drei Abrechnungsflächen, alles von Hand synchronisiert. Voice Live kollabiert das in eine einzige verwaltete API mit:

Semantische Sprachaktivitäts- und Sprechende-Erkennung (versteht Bedeutung, nicht nur Stille)
Serverseitige Rauschunterdrückung und Echokompensation
Barge-in-Unterstützung (Benutzer können mitten in der Antwort unterbrechen)

Sprachinteraktionen laufen durch die gleiche Agent-Runtime wie Text. Gleiche Evaluatoren, gleiche Traces, gleiche Kosten-Transparenz. Für Kundensupport, Außendienst oder Barrierefreiheits-Szenarien ersetzt das, was vorher eine individuelle Audio-Pipeline erforderte.

Evaluierungen: von der Checkbox zum kontinuierlichen Monitoring

Hier wird Foundry ernst bezüglich Produktionsqualität. Das Evaluierungs-System hat jetzt drei Schichten:

Mitgelieferte Evaluatoren — Kohärenz, Relevanz, Begründetheit, Retrieval-Qualität, Sicherheit. Verbinde mit einem Dataset oder Live-Traffic und erhalte Scores zurück.
Eigene Evaluatoren — kodiere deine eigene Geschäftslogik, Ton-Standards und domänenspezifische Compliance-Regeln.
Kontinuierliche Evaluierung — Foundry sampelt Live-Produktionstraffic, führt deine Evaluator-Suite aus und zeigt Ergebnisse in Dashboards. Setze Azure-Monitor-Alerts für sinkende Begründetheit oder Sicherheitsschwellen-Verletzungen.

Alles wird in Azure Monitor Application Insights veröffentlicht. Agent-Qualität, Infrastruktur-Gesundheit, Kosten und App-Telemetrie — alles an einem Ort.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Sechs neue Regionen für gehostete Agenten

Gehostete Agenten sind jetzt verfügbar in East US, North Central US, Sweden Central, Southeast Asia, Japan East und mehr. Das ist wichtig für Datenresidenz-Anforderungen und um Latenz zu komprimieren, wenn dein Agent nahe an seinen Datenquellen läuft.

Warum das für .NET-Entwickler wichtig ist

Auch wenn die Code-Samples im GA-Announcement Python-first sind, ist die zugrundeliegende Infrastruktur sprachunabhängig — und das .NET SDK für azure-ai-projects folgt den gleichen Mustern. Die Responses API, das Evaluierungs-Framework, das Private Networking, die MCP-Auth — all das ist von .NET aus verfügbar.

Wenn du darauf gewartet hast, dass KI-Agenten von “coole Demo” zu “kann ich tatsächlich auf der Arbeit ausliefern” werden, ist dieses GA-Release das Signal. Private Networking, ordentliche Auth, kontinuierliche Evaluierung und Produktions-Monitoring sind die Teile, die gefehlt haben.

Zusammenfassung

Foundry Agent Service ist jetzt verfügbar. Installiere das SDK, öffne das Portal und fang an zu bauen. Der Schnellstart-Guide bringt dich in Minuten von null zu einem laufenden Agenten.

Für den vollständigen technischen Deep-Dive mit allen Code-Samples, schau dir das GA-Announcement an.

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.

Dotnet | The .NET Blog

SDD Conference 2026

Themen

Speaker

Tickets und Infos

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

Was sind Hooks?

Wie die Erkennung funktioniert

Sprachspezifische Details

Python

JavaScript und TypeScript

.NET

Executor-spezifische Konfiguration

Warum das für .NET-Entwickler wichtig ist

Fazit

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

winapp run: F5 von überall

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

winapp ui: UI-Automatisierung aus der Kommandozeile

Weitere Neuerungen

Installation

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

Detached Mode: ein Befehl, Terminal zurück

Laufende Prozesse verwalten

Kombiniere es mit dem isolierten Modus

Warum das für Coding-Agents riesig ist

Fazit

Pin-Clustering landet endlich in .NET MAUI Maps — Eine Property, null Aufwand

Eine Property, sie alle zu beherrschen

Unabhängige Clustering-Gruppen

Cluster-Taps verarbeiten

Plattform-Details, die man kennen sollte

Warum das wichtig ist

Loslegen

.NET April 2026 Servicing — Sicherheitspatches, die du heute einspielen solltest

Was wurde gepatcht

Aktualisierte Versionen

Was zu tun ist

Azure MCP Server 2.0 ist da — Self-Hosted Agentic Cloud Automation ist Realität

Was ist Azure MCP Server?

Das Wichtigste: Self-Hosted Remote Deployments

Security Hardening

Wo kannst du es verwenden?

Warum das für .NET-Entwickler wichtig ist

Erste Schritte

Zusammenfassung

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

Das Problem ist real

Aspire als Agenten-Infrastruktur

Die Bowlingbahn-Bumper-Analogie

Erste Schritte

Zusammenfassung

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

Die Lösung: --isolated

Reale Szenarien, in denen das glänzt

Wie es unter der Haube funktioniert

Wann man es verwenden sollte

Zusammenfassung

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

MCP Apps bekommen eine Fluent API — Erstelle reichhaltige AI-Tool-UIs in .NET in drei Schritten

Was sind MCP Apps?

Die Fluent API in drei Schritten

Die API-Oberfläche ist gut durchdacht

Erste Schritte

Zusammenfassung

Verbinde deine MCP-Server auf Azure Functions mit Foundry Agents — So geht's

Warum diese Kombination Sinn macht

Authentifizierungsoptionen

Einrichtung

Meine Einschätzung

Zusammenfassung

C# 15 bekommt Union Types — und sie sind genau das, was wir uns gewünscht haben

Das Problem, das Unions lösen

Die Syntax ist wunderschön einfach

Die Lösung: `--isolated`