The .NET Blog

NDC Oslo 2026

Mon, 14 Sep 2026 00:00:00 +0000

NDC Oslo 2026 findet vom 14. bis 18. September 2026 im Oslo Spektrum in Oslo, Norwegen statt.

NDC Oslo ist eine der größten und angesehensten Entwicklerkonferenzen Europas, die alles abdeckt — von .NET und Cloud über Sicherheit, Architektur und KI bis darüber hinaus. Die Ausgabe 2026 befindet sich derzeit in der Buchungsphase, mit einem massiven Programm im Aufbau.

In Zahlen

160 Sessions (in Buchung)
150 Speaker (in Buchung)
15 Workshops (in Buchung)
5 Tage — Workshops + Konferenz

Bestätigte Speaker

Die Speaker-Liste wird aufgebaut, mit bestätigten Namen wie:

Nick Chapsas
Maddy Montaquila
Troy Hunt
Kevlin Henney
Venkat Subramaniam
Jeff Fritz
Philippe De Ryck
Nhlanhla Lucky Nkosi
Aleksander Stensby

Tickets

Early-Bird-Tickets sind verfügbar — das Early-Bird-Angebot endet am 22. Mai 2026.

Der CFP (Call for Papers) ist ebenfalls offen.

Weitere NDC-Events 2026

NDC Sydney — 22.–24. April 2026
NDC Toronto — 5.–8. Mai 2026
NDC Copenhagen — 1.–4. Juni 2026
NDC AI — 8.–10. Juni 2026
NDC TechTown — 21.–24. September 2026

.NET Day Switzerland 2026

Tue, 25 Aug 2026 00:00:00 +0000

.NET Day Switzerland 2026 findet am 25. August 2026 im Arena Cinemas Sihlcity (Kalanderplatz 8, 8045 Zürich) statt.

Dies ist eine unabhängige, gemeinnützige Community-Konferenz für Entwickler, Architekten und Experten zu .NET, C#, ASP.NET Core, Azure und dem gesamten Microsoft-Entwicklungsökosystem. Alle Speaker und Helfer arbeiten ehrenamtlich, und Überschüsse aus dem Ticketverkauf gehen an wohltätige Zwecke oder die Schweizer .NET-Community.

Das erwartet dich

Hochwertige Sessions von internationalen Fachexperten
Networking mit anderen Teilnehmern
Essen, Snacks und Getränke in den Pausen, beim Mittagessen und beim Apéro
Karrieremöglichkeiten durch Sponsor-Interaktionen
Direkte Gespräche mit Speakern in den Pausen

Tickets

Kategorie	Preis	Verfügbarkeit
Very Early Bird (1.–30. Apr)	299 CHF	Max. 100 Tickets
Early Bird	399 CHF	Max. 100 Tickets
Regular	449 CHF	Bis ausverkauft

Speaker und Programm sind noch nicht bekannt — der Call for Speakers ist auf Sessionize offen.

Organisatoren

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.

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

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

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

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

WIQL-Abfrageunterstützung

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

Personal Access Tokens

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

MCP-Annotationen

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

Wiki-Tool-Konsolidierung

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

Experimentell: MCP Apps

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

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

SQL Server 2025 als Agent-Ready Datenbank: Sicherheit, Backup und MCP in einer Engine

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

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

Ich habe die Polyglot Tax Serie von Aditya Badramraju mit großem Interesse verfolgt. Teile 1-3 lieferten den Beweis für SQL Server 2025 als echte Multi-Modell-Datenbank. Teil 4 schließt die Serie mit den Teilen, die wirklich bestimmen, ob du dieser Architektur in Produktion vertrauen würdest.

Ein Sicherheitsmodell für alle Datenmodelle

Eine Row-Level Security Policy, die alle Datenmodelle abdeckt — relationale Tabellen, JSON-Events, Graph-Edges, Vektoren. Eine Policy, ein Audit, ein Nachweis.

Einheitliches Backup = Atomare Wiederherstellung

In einem polyglottes Stack bedeutet Point-in-Time Recovery fünf koordinierte Restore-Operationen und die Hoffnung, dass die Timestamps übereinstimmen. Mit einer Datenbank ist die Wiederherstellung per Definition atomar.

MCP-Integration: Agenten Ohne Hand-codierten Middleware

SQL Server 2025 unterstützt den SQL MCP Server direkt. Agenten rufen Tools auf, die Engine erzwingt Tenant-Isolierung und Column-Masking automatisch.

Fazit

Für .NET-Entwickler, die agenten-first Anwendungen auf Azure SQL bauen, verdient diese Architektur ernsthafte Überlegung. Originalpost von Aditya Badramraju: The Polyglot Tax – Part 4.

.NET 10 wird mit Ubuntu 26.04 LTS ausgeliefert — Was Neu Ist

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

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

Es ist Ubuntu-LTS-Tag. Ubuntu 26.04 (Resolute Raccoon) ist heute erschienen und liefert wie jede Ubuntu-LTS die neueste .NET-LTS aus — in diesem Fall .NET 10.

LTS auf LTS — fünf Jahre Support für das OS, passend zum eigenen Langzeit-Support-Fenster von .NET 10.

.NET 10 in zwei Befehlen installieren

sudo apt update
sudo apt install dotnet-sdk-10.0

.NET ist einer der offiziell unterstützten Toolchains auf Ubuntu — kein Drittanbieter-Add-on.

Container: `-noble` zu `-resolute` aktualisieren

Die Migration ist einzeilig:

sed -i "s/noble/resolute/g" Dockerfile

Alle bestehenden Image-Varianten — einschließlich Chiseled — sind verfügbar.

Native AOT: 3ms Start, 1,4MB Binary

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# artifacts/app/app — 1,4MB natives Binary
# real 0m0.003s

Für cloud-native Workloads, bei denen Kaltstart-Zeit wichtig ist — Functions, Container, Serverless — ein echter Gamechanger.

Benötigst du .NET 8 oder 9?

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

Der vollständige Beitrag enthält weitere Details zu cgroup v2, Post-Quanten-Kryptografie und Linux 7.0.

Azure SDK April 2026: AI Foundry 2.0 und Was .NET-Entwickler Wissen Sollten

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

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

Das April SDK-Release hat einiges, das Beachtung verdient — besonders wenn du mit AI Foundry, Cosmos DB in Java oder Infrastructure Provisioning aus .NET-Code arbeitest.

Azure.AI.Projects 2.0.0 — Breaking Changes, die Sinn machen

Das Azure.AI.Projects NuGet-Paket erreicht stabile 2.0.0 mit significanten Änderungen: Namespace-Splits für Evaluations und Memory, umbenannte Typen und konsistente Is*-Konvention für Booleans.

Cosmos DB Java: Kritischer Sicherheitsfix (RCE)

Der Java Cosmos DB Library 4.79.0 enthält einen kritischen Fix für eine Remote Code Execution Schwachstelle (CWE-502). Sofort updaten.

Neue Provisioning-Bibliotheken für .NET

Fazit

Das Highlight für .NET-Entwickler diesen Monat: Azure.AI.Projects 2.0.0 ist stabil. Originalpost: Azure SDK Release (April 2026).

CodeAct im Agent Framework: Wie du die Latenz deines Agenten halbierst

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

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

Es gibt diesen Moment in jedem Agenten-Projekt, wo man auf den Trace schaut und denkt: „Warum dauert das so lange?" Das Modell ist gut. Die Tools funktionieren. Aber es gibt sieben Round Trips für ein Ergebnis, das man in einem Schritt berechnen könnte.

Genau dieses Problem löst CodeAct — und das Agent Framework Team hat soeben Alpha-Unterstützung dafür veröffentlicht mit dem neuen Paket agent-framework-hyperlight.

Was ist CodeAct?

Das CodeAct-Muster ist elegant einfach: Statt dem Modell eine Liste von Tools zu geben und sie einzeln aufrufen zu lassen, gibst du ihm ein einziges execute_code-Tool und lässt es den gesamten Plan als kurzes Python-Programm ausdrücken. Der Agent schreibt den Code einmal, die Sandbox führt ihn aus, und du erhältst ein einziges konsolidiertes Ergebnis zurück.

Ein Fünf-Schritte-Plan, der früher fünf Modell-Turns benötigte, wird zu einem einzigen execute_code-Turn mit einem Python-Script, das deine Tools über call_tool(...) aufruft.

Verdrahtung	Zeit	Tokens
Traditionell	27,81s	6.890
CodeAct	13,23s	2.489
Verbesserung	52,4%	63,9%

Die Sicherheitskomponente: Hyperlight Micro-VMs

Das Paket agent-framework-hyperlight verwendet Hyperlight Micro-VMs. Jeder execute_code-Aufruf erhält eine eigene frisch erstellte Micro-VM — mit eigenem Speicher, ohne Zugriff auf das Host-Dateisystem außer dem, was du explizit mountest. Der Start wird in Millisekunden gemessen. Die Isolierung ist im Grunde kostenlos.

Deine Tools laufen weiterhin auf dem Host. Der modellgenerierte Klebecode läuft in der Sandbox. Das ist die richtige Aufteilung.

Einrichtung

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Wann CodeAct verwenden (und wann nicht)

CodeAct verwenden, wenn:

Die Aufgabe viele kleine Tool-Aufrufe verkettet (Lookups, Joins, Berechnungen)
Latenz und Token-Kosten wichtig sind
Du starke Isolierung für modellgenerierten Code willst

Beim traditionellen Tool-Calling bleiben, wenn:

Der Agent nur ein oder zwei Tool-Aufrufe pro Turn macht
Jeder Aufruf Nebeneffekte hat, die einzeln genehmigt werden sollen
Tool-Beschreibungen spärlich oder mehrdeutig sind

Jetzt ausprobieren

pip install agent-framework-hyperlight --pre

Den vollständigen Beitrag findest du im Agent Framework Blog.

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

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

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

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

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

Was ist ein MCP Bundle?

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

Installation

1. Bundle für deine Plattform herunterladen

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

2. In Claude Desktop installieren

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

3. Bei Azure authentifizieren

az login

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

Was du damit machen kannst

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

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

Erste Schritte

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

Siehe den vollständigen Beitrag.

GPT-5.5 ist da und kommt zu Azure Foundry — Was .NET-Entwickler Wissen Müssen

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

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

Microsoft hat gerade bekannt gegeben, dass GPT-5.5 allgemein in Microsoft Foundry verfügbar ist. Wenn du Agenten auf Azure aufgebaut hast, ist das das Update, auf das du gewartet hast.

Die GPT-5-Progression

GPT-5: vereinte Reasoning und Geschwindigkeit in einem einzigen System
GPT-5.4: stärkeres Multi-Step-Reasoning, frühe agentische Fähigkeiten für Unternehmen
GPT-5.5: tieferes Langkontext-Reasoning, zuverlässigere agentische Ausführung, bessere Token-Effizienz

Was sich wirklich geändert hat

Verbessertes agentisches Coding: GPT-5.5 hält Kontext über große Codebasen hinweg, diagnostiziert Architekturfehler und antizipiert Testanforderungen. Das Modell überlegt, was sonst noch eine Korrektur beeinflusst.

Token-Effizienz: Höherwertigere Ausgaben mit weniger Tokens und weniger Wiederholungen. Direkt niedrigere Kosten und Latenz für Produktions-Deployments.

Langkontext-Analyse: Verarbeitet umfangreiche Dokumente und Multi-Session-Historien ohne den Faden zu verlieren.

Preise

Modell	Eingabe ($/M Tokens)	Gecachte Eingabe	Ausgabe ($/M Tokens)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Warum Foundry wichtig ist

Foundry Agent Service ermöglicht es, Agenten in YAML zu definieren oder sie mit Microsoft Agent Framework, GitHub Copilot SDK, LangGraph oder OpenAI Agents SDK zu verbinden — und sie als isolierte gehostete Agenten mit persistentem Dateisystem, eigener Microsoft Entra-Identität und Scale-to-zero-Preisen auszuführen.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Du bist ein hilfreicher Assistent.", name: "MeinAgent");

Sieh dir die vollständige Ankündigung für alle Details an.

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

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

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

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

Copilot CLI: Sitzungen bekommen echte Namen

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

Schneller zwischen Sitzungen wechseln

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

Modell-Badges im Chat

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

Automatische Modellauswahl in Copilot CLI

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

TypeScript 7.0 Nightly Opt-in

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

Sieh dir die vollständigen Release-Notes an.

Wo Erinnert sich dein Agent an Dinge? Ein Praxisleitfaden zur Chat-Verlauf-Speicherung

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

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

Beim Aufbau eines KI-Agenten investierst du die meiste Energie in Modell, Tools und Prompts. Die Frage, wo der Gesprächsverlauf lebt, scheint ein Implementierungsdetail — ist aber eine der wichtigsten Architekturentscheidungen, die du treffen wirst.

Sie bestimmt, ob Nutzer Gespräche verzweigen, Antworten rückgängig machen, Sitzungen nach einem Neustart fortsetzen können und ob deine Daten deine Infrastruktur jemals verlassen.

Zwei grundlegende Muster

Service-managed: Der KI-Dienst speichert den Gesprächszustand. Deine App hält eine Referenz und der Dienst fügt automatisch den relevanten Verlauf in jede Anfrage ein.

Client-managed: Deine App verwaltet den vollständigen Verlauf und sendet relevante Nachrichten mit jeder Anfrage. Der Dienst ist zustandslos. Du kontrollierst alles.

Wie Agent Framework das abstrahiert

// C# — funktioniert gleich, unabhängig vom Provider
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Mein Name ist Alice.", session);
var second = await agent.RunAsync("Wie ist mein Name?", session);

# Python
session = agent.create_session()
first = await agent.run("Mein Name ist Alice.", session=session)
second = await agent.run("Wie ist mein Name?", session=session)

Provider-Schnellreferenz

Provider	Speicherort	Modell	Komprimierung
OpenAI/Azure Chat Completions	Client	N/A	Du
Foundry Agent Service	Service	Linear	Service
Responses API (Standard)	Service	Verzweigend	Service
Anthropic Claude, Ollama	Client	N/A	Du

Wie du die Wahl triffst

Brauchst du Verzweigung oder „Rückgängig"? → Responses API service-managed
Brauchst du vollständige Datensouveränität? → Client-managed mit datenbankgestütztem Provider
Ist es ein einfacher Chatbot? → Service-managed linear reicht
Brauchst du Portabilität zwischen Providern? → Client-managed bietet Portabilität

Lies den vollständigen Beitrag für den vollständigen Entscheidungsbaum.

Aspire 13.2: Bun-Support, bessere Container und weniger Debug-Reibung

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

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

Wenn du .NET-Backends mit JavaScript-Frontends in Aspire baust, ist 13.2 das Update, das deinen Alltag leise besser macht. Keine neuen Paradigmen. Nur solide Verbesserungen an Dingen, die leicht nervig waren.

Bun ist jetzt erstklassig

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Wenn dein Team Bun bereits verwendet, zwingt Aspire dich nicht mehr gegen den Strom zu schwimmen.

Yarn wurde zuverlässiger

Yarn-Nutzer bekommen etwas mindestens genauso Wichtiges: weniger mysteriöse Fehler bei withYarn() mit addViteApp().

Container-Verbesserungen

Explizite Pull Policy

const worker = await builder.addContainer("worker", "myorg/worker:latest")
 .withImagePullPolicy(ImagePullPolicy.Never);

Perfekt für Workflows, wo du lokal Images baust und Compose genau dieses verwenden soll.

PostgreSQL 18+ funktioniert korrekt

PostgreSQL 18 änderte sein internes Verzeichnislayout, was das Volume-Mapping still brach. 13.2 behebt das.

Debugging-Verbesserungen

DebuggerDisplayAttribute auf Core-Typen — nützliche Werte statt tiefer Objektbäume
Bessere Fehlermeldungen für WaitFor
BeforeResourceStartedEvent feuert zum richtigen Zeitpunkt

Fazit

Aspire 13.2 ist ein fokussiertes Qualitäts-Release. Originalpost von David Pine: Aspire 13.2: Bun Support and Container Enhancements.

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

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

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

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

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

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

Die Kontextfenster-Lüge

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

Hier ist die tatsächliche Rechnung:

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

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

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

Die Kompaktierungssteuer

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

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

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

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

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

pip install auto-memory

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

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

Fazit

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

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

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

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

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

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

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

Was sind Hooks?

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

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

Wie die Erkennung funktioniert

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

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

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

Sprachspezifische Details

Python

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

JavaScript und TypeScript

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

.NET

Zwei Modi verfügbar:

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

Executor-spezifische Konfiguration

Jede Sprache unterstützt einen optionalen config-Block:

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

Warum das für .NET-Entwickler wichtig ist

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

Fazit

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

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

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

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

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

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

Was ist eine Toolbox?

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

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

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

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

Praktisches Beispiel

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

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

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

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

Kein Lock-in bei Foundry Agents

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

Warum das jetzt wichtig ist

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

Fazit

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

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

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

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

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

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

winapp run: F5 von überall

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

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

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

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

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

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

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

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

winapp ui: UI-Automatisierung aus der Kommandozeile

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

Was möglich ist:

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

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

Weitere Neuerungen

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

Installation

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

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

Jetzt patchen: .NET 10.0.7 OOB Sicherheitsupdate für ASP.NET Core Data Protection

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

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

Dieses Update ist nicht optional. Wenn deine Anwendung Microsoft.AspNetCore.DataProtection verwendet, musst du auf 10.0.7 aktualisieren.

Was Passiert Ist

Nach dem Patch Tuesday Release .NET 10.0.6 berichteten einige Benutzer von Entschlüsselungsfehlern. Während der Untersuchung entdeckte das Team die Sicherheitslücke CVE-2026-40372: Der HMAC-Validierungs-Tag wurde über die falschen Bytes berechnet, was zu Privilege Escalation führen konnte.

Wie Beheben

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

Dann neu bauen und deployen.

Originalankündigung von Rahul Bhandari: .NET 10.0.7 Out-of-Band Security Update.

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

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

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

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

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

Setup mit Copilot während azd init

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

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

Voraussetzungen:

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

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

Was es wirklich macht

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

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

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

Copilot-gestützte Fehlerbehebung

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

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

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

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

Typische Fehler, bei denen das glänzt

Ressourcenanbieter nicht registriert:

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

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

SKU nicht verfügbar:

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

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

Speicherkontoname bereits vergeben:

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

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

Standardverhalten konfigurieren

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

azd config set copilot.errorHandling.category troubleshoot

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

azd config set copilot.errorHandling.fix allow

Zurück zum interaktiven Modus jederzeit:

azd config unset copilot.errorHandling.category

Fazit

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

Den originalen Ankündigungsbeitrag findest du hier.

Node.js Native Addons in C# mit .NET Native AOT schreiben

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

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

Dieses Szenario gefällt mir: Ein Team, das an .NET-Tooling arbeitet, hatte native Node.js-Addons, die in C++ geschrieben und über node-gyp kompiliert wurden. Es funktionierte. Aber es erforderte Python auf jeder Entwicklermaschine — eine alte Python-Version wohlgemerkt — nur um ein Paket zu bauen, das niemand im Team direkt anfassen würde.

Also stellten sie eine sehr vernünftige Frage: Wir haben das .NET SDK bereits installiert, warum schreiben wir überhaupt C++?

Die Antwort war Native AOT, und das Ergebnis ist wirklich elegant. Drew Noakes vom C# Dev Kit-Team hat dokumentiert, wie sie es gemacht haben, und ich denke, es lohnt sich, das zu verstehen — auch wenn du keine VS Code-Extensions baust.

Die Grundidee

Ein nativer Node.js-Addon ist eine Shared Library (.dll unter Windows, .so unter Linux, .dylib unter macOS), die Node.js zur Laufzeit laden kann. Die Schnittstelle heißt N-API — eine stabile, ABI-kompatible C-API. N-API kümmert sich nicht darum, welche Sprache die Library produziert hat, nur dass sie die richtigen Symbole exportiert.

.NET Native AOT kann genau das produzieren. Es kompiliert C#-Code ahead-of-time in eine native Shared Library mit beliebigen Einstiegspunkten. Das ist der ganze Trick.

Projekt-Setup

Die Projektdatei ist minimal:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot weist das SDK an, bei dotnet publish eine Shared Library zu produzieren. AllowUnsafeBlocks wird für das N-API-Interop mit Funktionszeigern und Fixed Buffers benötigt.

Den Einstiegspunkt exportieren

Node.js erwartet, dass deine Library napi_register_module_v1 exportiert. In C# macht [UnmanagedCallersOnly] genau das:

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

Ein paar Dinge, die erwähnenswert sind: nint ist ein nativer Integer — das verwaltete Äquivalent von intptr_t. Das u8-Suffix produziert einen ReadOnlySpan<byte> mit einem UTF-8-String-Literal, direkt an N-API übergeben ohne jede Encoding-Allokation. Und [UnmanagedCallersOnly] exportiert die Methode mit genau dem Einstiegspunkt-Namen, den Node.js sucht.

N-API gegen den Host-Prozess auflösen

N-API-Funktionen werden von node.exe selbst exportiert, nicht von einer separaten Library. Statt gegen etwas zu linken, werden sie beim Start gegen den laufenden Prozess aufgelöst:

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

Damit funktionieren P/Invoke-Deklarationen sauber mit [LibraryImport] und quellegenerierten Marshalling.

Eine echte exportierte Funktion

Hier ist der Registry-Reader, den sie gebaut haben:

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

Wichtiger Hinweis zum try/catch: Eine unbehandelte Exception in einer [UnmanagedCallersOnly]-Methode stürzt den Host-Prozess ab. Immer abfangen und via ThrowError an JavaScript weiterleiten.

Von TypeScript aufrufen

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk', 'InstallLocation');

TypeScript → C#, kein Python, kein C++.

Was sie gewonnen haben

Der sofortige Gewinn war die Contributor-Experience: keine bestimmte Python-Version mehr nötig, yarn install funktioniert mit Node.js und dem .NET SDK. CI-Pipelines wurden ebenfalls einfacher. Die Performance war vergleichbar mit der C++-Implementierung.

Fazit

Das C# Dev Kit-Team ersetzte Python/C++-Overhead durch sauberen C#-Code, den jeder im Team schon kann. Den vollständigen Walkthrough mit allen String-Marshalling-Helfern findest du im Originalartikel auf dem .NET-Blog.

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

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

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

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

Hier ist, was wirklich zählt.

Autopilot-Modus merkt sich endlich deine Einstellung

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

Der Agent Host unterstützt drei Session-Konfigurationen:

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

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

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

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

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

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

Subagents und Agent-Teams

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

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

Terminal-Output wird automatisch mitgeliefert, wenn Agents Input senden

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

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

Die Agents-App auf macOS aktualisiert sich selbst

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

Die kleineren Dinge, die es wert sind zu wissen

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

Das Fazit

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

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

Deine KI-Experimente auf Azure verbrennen Geld — So behebst du das

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

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

Wenn du gerade KI-gestützte Apps auf Azure baust, ist dir wahrscheinlich etwas aufgefallen: Deine Cloud-Rechnung sieht anders aus als früher. Nicht nur höher — seltsamer. Sprunghaft. Schwer vorhersagbar.

Microsoft hat gerade einen großartigen Beitrag über Cloud-Kostenoptimierungsprinzipien, die immer noch wichtig sind veröffentlicht, und ehrlich gesagt könnte das Timing nicht besser sein. Denn KI-Workloads haben die Spielregeln bei den Kosten verändert.

Warum KI-Workloads anders zuschlagen

Hier ist die Sache. Traditionelle .NET-Workloads sind relativ vorhersagbar. Du kennst deinen App-Service-Tier, du kennst deine SQL-DTUs, du kannst die monatlichen Ausgaben ziemlich genau abschätzen. KI-Workloads? Nicht so sehr.

Du testest mehrere Modelle, um zu sehen, welches passt. Du fährst GPU-gestützte Infrastruktur für Fine-Tuning hoch. Du machst API-Aufrufe an Azure OpenAI, bei denen der Token-Verbrauch je nach Prompt-Länge und Benutzerverhalten stark variiert. Jedes Experiment kostet echtes Geld, und du führst vielleicht Dutzende durch, bevor du den richtigen Ansatz findest.

Diese Unvorhersehbarkeit macht Kostenoptimierung kritisch — nicht als Nachgedanke, sondern von Tag eins an.

Management vs. Optimierung — kenne den Unterschied

Eine Unterscheidung aus dem Artikel, die Entwickler meiner Meinung nach übersehen: Es gibt einen Unterschied zwischen Kosten-Management und Kosten-Optimierung.

Management bedeutet Tracking und Reporting. Du richtest Budgets in Azure Cost Management ein, bekommst Benachrichtigungen, siehst Dashboards. Das ist die Grundlage.

Optimierung ist da, wo du tatsächlich Entscheidungen triffst. Brauchst du wirklich diesen S3-Tier, oder würde S1 deine Last bewältigen? Steht diese Always-on-Compute-Instanz am Wochenende untätig herum? Könntest du Spot-Instanzen für deine Trainingsjobs verwenden?

Als .NET-Entwickler neigen wir dazu, uns auf den Code zu konzentrieren und die Infrastrukturentscheidungen dem „Ops-Team" zu überlassen. Aber wenn du auf Azure deployst, sind diese Entscheidungen auch deine Entscheidungen.

Was wirklich funktioniert

Basierend auf dem Artikel und meiner eigenen Erfahrung — das macht den Unterschied:

Wisse, was du ausgibst und wofür. Tagge deine Ressourcen. Im Ernst. Wenn du nicht erkennen kannst, welches Projekt oder Experiment dein Budget auffrisst, kannst du nichts optimieren. Azure Cost Management mit ordentlichem Tagging ist dein bester Freund.

Setze Leitplanken, bevor du experimentierst. Nutze Azure Policy, um teure SKUs in Dev/Test-Umgebungen einzuschränken. Setze Ausgabenlimits für deine Azure-OpenAI-Deployments. Warte nicht, bis die Rechnung kommt, um festzustellen, dass jemand ein GPU-Cluster über das Wochenende laufen gelassen hat.

Dimensioniere kontinuierlich richtig. Die VM, die du beim Prototyping ausgewählt hast? Die ist wahrscheinlich falsch für die Produktion. Azure Advisor gibt dir Empfehlungen — schau sie dir tatsächlich an. Überprüfe monatlich, nicht jährlich.

Denke an den Lebenszyklus. Entwicklungsressourcen sollten heruntergefahren werden. Testumgebungen müssen nicht 24/7 laufen. Nutze Auto-Shutdown-Richtlinien. Für KI-Workloads im Speziellen solltest du Serverless-Optionen in Betracht ziehen, bei denen du pro Ausführung zahlst, statt Compute warmzuhalten.

Miss den Wert, nicht nur die Kosten. Das vergisst man leicht. Ein Modell, das mehr kostet, aber deutlich bessere Ergebnisse liefert, könnte die richtige Wahl sein. Das Ziel ist nicht, am wenigsten auszugeben — sondern klug auszugeben.

Das Fazit

Cloud-Kostenoptimierung ist kein einmaliges Aufräumen. Es ist eine Gewohnheit. Und da KI-Workloads die Ausgaben unvorhersehbarer machen als je zuvor, erspart dir der frühe Aufbau dieser Gewohnheit schmerzhafte Überraschungen später.

Wenn du ein .NET-Entwickler bist, der auf Azure baut, fang an, deine Cloud-Rechnung wie deinen Code zu behandeln — überprüfe sie regelmäßig, refaktoriere, wenn es unordentlich wird, und deploye nie, ohne zu verstehen, was es dich kosten wird.

Foundrys RFT ist jetzt günstiger und intelligenter — Das hat sich geändert

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

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

Wenn ihr .NET-Apps entwickelt, die auf fine-getunte Modelle angewiesen sind, solltet ihr die Foundry-Updates dieses Monats im Auge behalten. Reinforcement Fine-Tuning ist jetzt zugänglicher und deutlich günstiger geworden.

Die vollständigen Details findet ihr in der offiziellen Ankündigung, aber hier ist die praktische Zusammenfassung.

Globales Training für o4-mini

o4-mini ist das Go-to-Modell für reasoning-intensive und agentenbasierte Workloads. Die große Neuigkeit: Ihr könnt jetzt Fine-Tuning-Jobs aus über 13 Azure-Regionen starten, mit niedrigeren Pro-Token-Trainingskosten im Vergleich zum Standard-Training. Gleiche Infrastruktur, gleiche Qualität, größere Reichweite.

Wenn euer Team über verschiedene Regionen verteilt ist, ist das relevant. Ihr seid nicht mehr auf eine Handvoll Regionen zum Trainieren beschränkt.

Hier ist der REST-API-Aufruf, um einen globalen Trainingsjob zu starten:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Dieses trainingType: globalstandard-Flag ist der entscheidende Unterschied.

Neue Model-Grader: GPT-4.1-Familie

Grader definieren das Belohnungssignal, gegen das euer Modell optimiert. Bisher waren modellbasierte Grader auf eine kleinere Auswahl von Modellen beschränkt. Jetzt habt ihr drei neue Optionen: GPT-4.1, GPT-4.1-mini und GPT-4.1-nano.

Wann solltet ihr Model-Grader statt deterministischer Grader verwenden? Wenn eure Aufgabenausgabe offen ist, wenn ihr partielle Bewertung über mehrere Dimensionen braucht, oder wenn ihr agentenbasierte Workflows baut, bei denen die Korrektheit von Tool-Aufrufen vom semantischen Kontext abhängt.

Die Sache ist — die Tier-Strategie ist praktisch:

GPT-4.1-nano für erste Iterationen. Niedrige Kosten, schnelle Feedback-Schleifen.
GPT-4.1-mini sobald eure Bewertungsrubrik stabil ist und ihr höhere Genauigkeit braucht.
GPT-4.1 für Produktionsbewertung oder komplexe Rubriken, bei denen jede Bewertungsentscheidung zählt.

Ihr könnt sogar Grader-Typen in einem einzigen RFT-Job mischen. Verwendet String-Match für die “richtige Antwort”-Dimension und einen Model-Grader zur Bewertung der Reasoning-Qualität. Diese Flexibilität ist ehrlich gesagt das, was es für echte Workloads nützlich macht.

Die Stolperfalle beim RFT-Datenformat

Hierüber stolpern viele. Das RFT-Datenformat unterscheidet sich von SFT. Die letzte Nachricht in jeder Zeile muss eine User- oder Developer-Rolle haben — nicht Assistant. Die erwartete Antwort kommt in einen Top-Level-Schlüssel wie reference_answer, auf den der Grader direkt verweist.

Wenn ihr bisher Supervised Fine-Tuning gemacht habt und auf RFT umsteigen wollt, müsst ihr eure Trainingsdaten umstrukturieren. Überspringt diesen Schritt nicht, sonst schlagen eure Jobs stillschweigend fehl.

Warum das für .NET-Entwickler wichtig ist

Wenn ihr fine-getunte Modelle aus euren .NET-Apps über das Azure OpenAI SDK aufruft, bedeutet günstigeres Training, dass ihr aggressiver iterieren könnt. Die Model-Grader-Optionen bedeuten, dass ihr für nuancierte Aufgaben fine-tunen könnt — nicht nur für Exact-Match-Szenarien. Und der Best-Practices-Leitfaden auf GitHub wird euch echte Debugging-Zeit sparen.

Fangt klein an. Zehn bis hundert Samples. Einfacher Grader. Validiert den Loop. Dann skaliert.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 findet am 18. April 2026 im Kinépolis Diversia in Alcobendas, Madrid statt. Es ist das größte Community-Azure-Event in Spanien, mit 38 Speakern auf 3 parallelen Tracks zu KI-Agenten, Azure-Netzwerken, Cosmos DB, Fabric, IoT, Sicherheit und vielem mehr.

Das Event läuft von 08:30 bis 18:30 und beinhaltet Keynote, Kaffeepausen, Mittagessen und eine Abschluss-Q&A-Session.

Highlights der Agenda

Domando Agentes de IA: Governance, Tools und APIs mit Azure AI Foundry und Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: Multi-Agenten-Systeme in Aktion
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Tickets

Die Anmeldung erfolgt als symbolische Spende — der gesamte Ticketpreis geht direkt an Plan International für Kinderrechte und Gleichstellung weltweit. Begrenzte Kapazität, also sicher dir rechtzeitig einen Platz.

Azure Tour 2026

Neben Madrid umfasst die Global Azure Tour 2026 auch Stationen in Zaragoza, Teneriffa und Sevilla.

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

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

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

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

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

Was Docker Sandbox tatsächlich bietet

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

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

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

Warum .NET-Entwickler aufhorchen sollten

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

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

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

Der Sicherheitsaspekt zählt

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

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

Fazit

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

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

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

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

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

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

Detached Mode: ein Befehl, Terminal zurück

aspire start

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

Laufende Prozesse verwalten

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

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

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

Kombiniere es mit dem isolierten Modus

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

aspire start --isolated
aspire start --isolated

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

Warum das für Coding-Agents riesig ist

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

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

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

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

Fazit

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

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

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

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

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

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

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

Was das konkret bedeutet

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

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

Warum das wichtiger ist als es klingt

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

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

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

Was du damit machen kannst

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

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

Ein schnelles Beispiel — tippe das in Copilot Chat:

List my storage accounts in my current subscription.

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

So aktivierst du es

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

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

Ein Hinweis

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

Das große Bild

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

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

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.

Aspire 13.2 bringt MongoDB EF Core und Azure Data Lake — Zwei Integrationen, die einen Blick wert sind

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

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

Aspire 13.2 ist gerade erschienen mit zwei neuen Datenbank-Integrationen, die eure Aufmerksamkeit verdienen: MongoDB Entity Framework Core und Azure Data Lake Storage. Wenn ihr EF Core mit MongoDB in einer Aspire-App nutzen wolltet, oder Data-Lake-Workloads mit ordentlichem Service Discovery anbinden müsst, liefert dieses Release beides.

MongoDB trifft EF Core in Aspire

Das ist die Integration, auf die ich mich am meisten freue. Aspire hat MongoDB schon länger unterstützt, aber es war immer der rohe Treiber — kein EF Core, kein DbContext, keine LINQ-Abfragen gegen eure Dokumente. Jetzt bekommt ihr die volle EF-Core-Erfahrung mit MongoDB, plus Aspires automatische Health Checks und Service Discovery.

Die Einrichtung folgt dem typischen Aspire-Muster. Im AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Dann fügt ihr in eurem konsumierenden Projekt die EF Core Integration hinzu:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Und registriert euren DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Ab da ist es Standard-EF-Core. Definiert eure Entities, nutzt euren DbContext wie mit jedem anderen Provider. Die Integration übernimmt Connection Pooling, OpenTelemetry-Traces und Health Checks im Hintergrund.

Für .NET-Entwickler, die MongoDB mit dem rohen Treiber genutzt und Connection Strings manuell verdrahtet haben, ist das ein schönes Upgrade. Ihr bekommt die volle EF-Core-Abstraktion, ohne Aspires Service Discovery zu verlieren.

Azure Data Lake Storage ist mit dabei

Die zweite große Neuerung ist eine Azure Data Lake Storage (ADLS) Integration. Wenn ihr Datenpipelines, ETL-Prozesse oder Analyseplattformen baut, könnt ihr Data-Lake-Ressourcen jetzt genauso anbinden wie jede andere Aspire-Abhängigkeit.

Im AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Im konsumierenden Projekt:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Keine manuelle Connection-String-Verwaltung, keine Credential-Suche. Aspire provisioniert Ressourcen und injiziert sie. Für diejenigen von uns, die cloud-native .NET-Apps bauen, die sowohl operative Daten als auch Analyse-Workloads berühren, fühlt sich der Data Lake damit wie ein erstklassiger Bürger im Aspire-Modell an.

Die kleinen Verbesserungen, die zählen

Neben den Hauptfeatures gibt es ein paar Verbesserungen, die erwähnenswert sind:

MongoDB Connection String Fix — der Schrägstrich vor dem Datenbanknamen wird jetzt korrekt behandelt. Falls ihr einen Workaround dafür hattet, könnt ihr ihn entfernen
SQL Server Exports — Aspire.Hosting.SqlServer exportiert jetzt zusätzliche Serverkonfigurationsoptionen für feingranulare Kontrolle
Emulator-Updates — ServiceBus Emulator 2.0.0, App Configuration Emulator 1.0.2, und der Preview-Emulator von CosmosDB enthält jetzt einen Readiness Check
Azure Managed Redis — nutzt jetzt standardmäßig rediss:// (Redis Secure), sodass Verbindungen von Haus aus verschlüsselt sind

Der letzte Punkt ist subtil, aber wichtig — verschlüsseltes Redis als Standard bedeutet eine Sache weniger, die man in Produktion konfigurieren muss.

Fazit

Aspire 13.2 ist ein inkrementelles Release, aber die MongoDB EF Core und Data Lake Integrationen füllen echte Lücken. Wenn ihr auf ordentlichen EF-Core-Support mit MongoDB in Aspire gewartet habt, oder Data Lake als erstklassige Abhängigkeit braucht, upgradet auf 13.2 und probiert es aus. Der aspire add Befehl erstellt alles, was ihr braucht.

Lest die vollständigen Release Notes für mehr Details und schaut euch die Integrationsgalerie für die komplette Liste an.

azd update — Ein Befehl für alle deine Paketmanager

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

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

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

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

So funktioniert’s

azd update

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

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

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

Der kleine Haken

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

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

Warum das wichtig ist

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

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

Azure DevOps Server April 2026 Patch — Fix für PR-Abschluss und Sicherheitsupdates

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

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

Kurzer Hinweis für Teams, die selbst gehosteten Azure DevOps Server betreiben: Microsoft hat Patch 3 für April 2026 mit drei gezielten Fixes veröffentlicht.

Was behoben wurde

Fehlgeschlagene Pull-Request-Abschlüsse — eine Null-Referenz-Ausnahme beim automatischen Abschluss von Work Items konnte dazu führen, dass PR-Merges fehlschlugen. Wenn du auf zufällige Fehler beim PR-Abschluss gestoßen bist, ist das wahrscheinlich die Ursache
Validierung der Abmelde-Weiterleitung — verbesserte Validierung beim Abmelden, um potenziell bösartige Weiterleitungen zu verhindern. Das ist ein Sicherheitsfix, den man zeitnah anwenden sollte
GitHub Enterprise Server PAT-Verbindungen — das Erstellen von Personal-Access-Token-Verbindungen zu GitHub Enterprise Server war defekt, jetzt funktioniert es wieder

So aktualisierst du

Lade Patch 3 herunter und starte den Installer. Um zu überprüfen, ob der Patch angewendet wurde:

<patch-installer>.exe CheckInstall

Wenn du Azure DevOps Server on-premises betreibst, empfiehlt Microsoft dringend, immer auf dem neuesten Patch zu bleiben — sowohl für Sicherheit als auch Zuverlässigkeit. Schau dir die Release Notes für alle Details an.

Azure Smart Tier ist GA — Automatische Kostenoptimierung für Blob Storage ohne Lifecycle-Regeln

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

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

Wenn du jemals Zeit damit verbracht hast, Azure Blob Storage Lifecycle-Richtlinien zu optimieren und dann zugesehen hast, wie sie auseinanderfallen, sobald sich die Zugriffsmuster geändert haben, ist das hier für dich. Microsoft hat gerade die allgemeine Verfügbarkeit von Smart Tier für Azure Blob und Data Lake Storage angekündigt — eine vollständig verwaltete Tiering-Funktion, die Objekte automatisch zwischen Hot-, Cool- und Cold-Tiers basierend auf der tatsächlichen Nutzung verschiebt.

Was Smart Tier tatsächlich macht

Das Konzept ist einfach: Smart Tier wertet kontinuierlich die letzte Zugriffszeit jedes Objekts in deinem Speicherkonto aus. Häufig abgerufene Daten bleiben in Hot, inaktive Daten werden nach 30 Tagen nach Cool verschoben und nach weiteren 60 Tagen nach Cold. Wenn auf die Daten erneut zugegriffen wird, werden sie sofort wieder auf Hot hochgestuft. Der Zyklus beginnt von vorne.

Keine Lifecycle-Regeln zu konfigurieren. Keine Vorhersagen von Zugriffsmustern. Kein manuelles Tuning.

Während der Preview berichtete Microsoft, dass über 50% der von Smart Tier verwalteten Kapazität automatisch in kühlere Tiers verschoben wurde — basierend auf tatsächlichen Zugriffsmustern. Das ist eine deutliche Kostenreduzierung für große Speicherkonten.

Warum das für .NET-Entwickler wichtig ist

Wenn du Anwendungen baust, die Logs, Telemetrie, Analysedaten oder irgendeine Art von wachsendem Datenbestand erzeugen — und mal ehrlich, wer tut das nicht? — summieren sich die Speicherkosten schnell. Der traditionelle Ansatz war, Lifecycle-Management-Richtlinien zu schreiben, sie zu testen und dann neu anzupassen, wenn sich die Zugriffsmuster deiner App geändert haben. Smart Tier eliminiert diesen gesamten Workflow.

Einige praktische Szenarien, in denen das hilft:

Anwendungstelemetrie und Logs — Hot beim Debuggen, nach ein paar Wochen kaum noch abgerufen
Datenpipelines und ETL-Ausgaben — während der Verarbeitung stark genutzt, danach meistens Cold
Benutzergenerierte Inhalte — aktuelle Uploads sind Hot, ältere Inhalte kühlen allmählich ab
Backup- und Archivdaten — gelegentlich für Compliance abgerufen, meistens inaktiv

Einrichtung

Smart Tier zu aktivieren ist eine einmalige Konfiguration:

Neue Konten: Wähle Smart Tier als Standard-Zugangstier während der Erstellung des Speicherkontos (zonale Redundanz erforderlich)
Bestehende Konten: Wechsle den Blob-Zugangstier von deiner aktuellen Standardeinstellung zu Smart Tier

Objekte kleiner als 128 KiB bleiben in Hot und verursachen keine Überwachungsgebühr. Für alles andere zahlst du die Standard-Kapazitätstarife für Hot/Cool/Cold — ohne Tier-Übergangsgebühren, ohne Gebühren für vorzeitige Löschung und ohne Datenabrufkosten. Eine monatliche Überwachungsgebühr pro Objekt deckt die Orchestrierung ab.

Der Kompromiss, den du kennen solltest

Die Tiering-Regeln von Smart Tier sind statisch (30 Tage → Cool, 90 Tage → Cold). Wenn du benutzerdefinierte Schwellenwerte brauchst — zum Beispiel nach 7 Tagen für eine bestimmte Workload nach Cool verschieben — sind Lifecycle-Regeln weiterhin der richtige Weg. Und mische nicht beides: Vermeide es, Lifecycle-Regeln auf von Smart Tier verwaltete Objekte anzuwenden, da sie in Konflikt geraten können.

Fazit

Das ist nicht revolutionär, aber es löst ein echtes operatives Problem. Wenn du wachsende Blob-Storage-Konten verwaltest und es leid bist, Lifecycle-Richtlinien zu pflegen, aktiviere Smart Tier und lass Azure sich darum kümmern. Es ist heute in fast allen zonalen Public-Cloud-Regionen verfügbar.

Wo solltest du deine KI-Agenten auf Azure hosten? Ein praktischer Entscheidungsleitfaden

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

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

Wenn du gerade KI-Agenten mit .NET baust, hast du wahrscheinlich etwas bemerkt: Es gibt viele Möglichkeiten, sie auf Azure zu hosten. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — und alle klingen vernünftig, bis du tatsächlich einen auswählen musst. Microsoft hat gerade einen umfassenden Leitfaden zum Azure KI-Agenten-Hosting veröffentlicht, der das klärt, und ich möchte ihn aus der praktischen Perspektive eines .NET-Entwicklers aufschlüsseln.

Die sechs Optionen auf einen Blick

So würde ich die Landschaft zusammenfassen:

Option	Am besten für	Du verwaltest
Container Apps	Volle Container-Kontrolle ohne K8s-Komplexität	Observability, State, Lifecycle
AKS	Enterprise-Compliance, Multi-Cluster, Custom Networking	Alles (das ist der Punkt)
Azure Functions	Event-getriebene, kurzlebige Agenten-Tasks	Kaum etwas — echtes Serverless
App Service	Einfache HTTP-Agenten, vorhersehbarer Traffic	Deployment, Scaling-Config
Foundry Agents	Code-optionale Agenten über Portal/SDK	Fast nichts
Foundry Hosted Agents	Custom-Framework-Agenten mit verwalteter Infra	Nur dein Agenten-Code

Die ersten vier sind General-Purpose Compute — du kannst Agenten darauf ausführen, aber sie wurden nicht dafür entwickelt. Die letzten zwei sind agenten-nativ: Sie verstehen Konversationen, Tool-Aufrufe und Agenten-Lifecycles als First-Class-Konzepte.

Foundry Hosted Agents — der Sweet Spot für .NET-Agenten-Entwickler

Das hat meine Aufmerksamkeit geweckt. Foundry Hosted Agents sitzen genau in der Mitte: Du bekommst die Flexibilität, deinen eigenen Code auszuführen (Semantic Kernel, Agent Framework, LangGraph — was auch immer), aber die Plattform kümmert sich um Infrastruktur, Observability und Konversationsmanagement.

Das Schlüsselstück ist der Hosting Adapter — eine dünne Abstraktionsschicht, die dein Agenten-Framework mit der Foundry-Plattform verbindet. Für Microsoft Agent Framework sieht das so aus:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Das ist deine gesamte Hosting-Geschichte. Der Adapter übernimmt Protokollübersetzung, Streaming über Server-Sent Events, Konversationsverlauf und OpenTelemetry-Tracing — alles automatisch. Keine Custom Middleware, kein manuelles Plumbing.

Deployment ist wirklich einfach

Ich habe vorher Agenten auf Container Apps deployed und es funktioniert, aber man schreibt am Ende viel Glue-Code für State Management und Observability. Mit Hosted Agents und azd sieht das Deployment so aus:

# KI-Agenten-Extension installieren
azd ext install azure.ai.agents

# Von einer Vorlage initialisieren
azd ai agent init

# Bauen, pushen, deployen — fertig
azd up

Dieses einzelne azd up baut deinen Container, pusht ihn zu ACR, provisioniert das Foundry-Projekt, deployed Model-Endpoints und startet deinen Agenten. Fünf Schritte in einem Befehl zusammengefasst.

Integriertes Konversationsmanagement

Das ist der Teil, der in der Produktion am meisten Zeit spart. Anstatt deinen eigenen Konversations-State-Store zu bauen, handhaben Hosted Agents das nativ:

# Eine persistente Konversation erstellen
conversation = openai_client.conversations.create()

# Erste Runde
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Zweite Runde — Kontext bleibt erhalten
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Kein Redis. Kein Cosmos DB Session Store. Keine Custom Middleware für Nachrichtenserialisierung. Die Plattform kümmert sich einfach darum.

Mein Entscheidungsframework

Nachdem ich alle sechs Optionen durchgegangen bin, hier mein schnelles mentales Modell:

Brauchst du null Infrastruktur? → Foundry Agents (Portal/SDK, keine Container)
Hast du Custom-Agenten-Code, willst aber verwaltetes Hosting? → Foundry Hosted Agents
Brauchst du event-getriebene, kurzlebige Agenten-Tasks? → Azure Functions
Brauchst du maximale Container-Kontrolle ohne K8s? → Container Apps
Brauchst du strikte Compliance und Multi-Cluster? → AKS
Hast du einen einfachen HTTP-Agenten mit vorhersehbarem Traffic? → App Service

Für die meisten .NET-Entwickler, die mit Semantic Kernel oder Microsoft Agent Framework bauen, sind Hosted Agents wahrscheinlich der richtige Startpunkt. Du bekommst Scale-to-Zero, integriertes OpenTelemetry, Konversationsmanagement und Framework-Flexibilität — ohne Kubernetes zu verwalten oder deinen eigenen Observability-Stack aufzubauen.

Zum Abschluss

Die Agenten-Hosting-Landschaft auf Azure reift schnell. Wenn du heute ein neues KI-Agenten-Projekt startest, würde ich Foundry Hosted Agents ernsthaft in Betracht ziehen, bevor du aus Gewohnheit zu Container Apps oder AKS greifst. Die verwaltete Infrastruktur spart echte Zeit, und das Hosting-Adapter-Pattern lässt dich deine Framework-Wahl behalten.

Schau dir den vollständigen Leitfaden von Microsoft und das Foundry Samples Repo für funktionierende Beispiele an.

Agent Skills in .NET sind jetzt richtig flexibel

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

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

Wenn ihr Agenten mit dem Microsoft Agent Framework baut, kennt ihr den Ablauf: Skills definieren, in einen Provider einbinden und den Agenten entscheiden lassen, welchen er aufruft. Neu ist wie ihr diese Skills erstellt — und der Flexibilitätssprung ist erheblich.

Das neueste Update führt drei verschiedene Authoring-Patterns für Agent Skills ein: dateibasiert, klassenbasiert und inline-codedefiniert. Alle drei werden über einen einzigen AgentSkillsProviderBuilder verbunden, sodass ihr sie ohne Routing-Logik oder speziellen Glue-Code mischen könnt. Ich zeige euch jedes Pattern und wann ihr es einsetzen solltet.

Dateibasierte Skills: der Einstiegspunkt

Dateibasierte Skills sind genau das, wonach sie klingen — ein Verzeichnis auf der Festplatte mit einer SKILL.md-Datei, optionalen Scripts und Referenzdokumenten. Die einfachste Art, eurem Agenten neue Fähigkeiten zu geben:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

Das SKILL.md-Frontmatter deklariert den Skill-Namen und die Beschreibung, und der Instruktionsabschnitt sagt dem Agenten, wie er Scripts und Referenzen nutzen soll:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Dann verbindet ihr es mit SubprocessScriptRunner.RunAsync für die Script-Ausführung:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

Der Agent entdeckt den Skill automatisch und ruft das Provisioning-Script auf, wenn er den Kontostatus prüfen muss. Sauber und einfach.

Klassenbasierte Skills: per NuGet ausliefern

Hier wird es für Teams interessant. Klassenbasierte Skills leiten von AgentClassSkill<T> ab und verwenden Attribute wie [AgentSkillResource] und [AgentSkillScript], damit das Framework alles per Reflection entdeckt:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Das Schöne daran: Ein Team kann das als NuGet-Paket verpacken. Ihr fügt es eurem Projekt hinzu, steckt es in den Builder und es funktioniert neben euren dateibasierten Skills ohne Koordination:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Beide Skills erscheinen im System-Prompt des Agenten. Der Agent entscheidet basierend auf dem Gespräch, welchen er nutzt — kein Routing-Code nötig.

Inline Skills: die schnelle Brücke

Kennt ihr das, wenn ein anderes Team genau den Skill baut, den ihr braucht, aber erst im nächsten Sprint fertig wird? AgentInlineSkill ist eure Brücke:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Fügt ihn genauso wie die anderen zum Builder hinzu:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Wenn das NuGet-Paket irgendwann erscheint, tauscht ihr den Inline-Skill gegen die klassenbasierte Version aus. Der Agent merkt den Unterschied nicht.

Inline Skills sind aber nicht nur für Brücken. Sie sind auch die richtige Wahl, wenn ihr Skills dynamisch zur Laufzeit generieren müsst — denkt an einen Skill pro Geschäftsbereich aus einer Konfiguration geladen — oder wenn ein Script lokalen State erfassen muss, der nicht in einen DI-Container gehört.

Script-Genehmigung: Mensch in der Schleife

Für uns .NET-Entwickler, die Produktionsagenten bauen, ist das der Teil, der Deployment-Gespräche wirklich freischaltet. Manche Scripts haben echte Konsequenzen — jemanden in Benefits einschreiben, Produktionsinfrastruktur abfragen. Aktiviert UseScriptApproval und der Agent pausiert vor jeder Script-Ausführung:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Wenn der Agent ein Script ausführen will, gibt er stattdessen eine Genehmigungsanfrage zurück. Eure App sammelt die Entscheidung — genehmigen oder ablehnen — und der Agent fährt entsprechend fort. In regulierten Umgebungen ist das der Unterschied zwischen “wir können das deployen” und “die Rechtsabteilung sagt nein.”

Warum diese Kombination wichtig ist

Die echte Stärke liegt nicht in einem einzelnen Authoring-Pattern — sondern in der Komposition. Ihr könnt:

Klein anfangen mit einem dateibasierten Skill, die Instruktionen iterieren und ohne C# veröffentlichen
Wiederverwendbare Skills als NuGet-Pakete ausliefern, die andere Teams mit einer Zeile hinzufügen können
Lücken überbrücken mit Inline Skills, wenn ihr etwas jetzt braucht
Gemeinsame Skill-Verzeichnisse filtern mit Predicates, damit euer Agent nur das lädt, was er soll
Menschliche Aufsicht hinzufügen für Scripts, die Produktionssysteme berühren

All das wird über AgentSkillsProviderBuilder zusammengesetzt. Kein spezielles Routing, keine bedingte Logik, keine Skill-Typ-Prüfungen.

Zum Abschluss

Agent Skills in .NET haben jetzt ein wirklich flexibles Authoring-Modell. Ob ihr ein Solo-Entwickler seid, der mit dateibasierten Skills einen Prototyp skizziert, oder ein Enterprise-Team, das verpackte Fähigkeiten per NuGet ausliefert — die Patterns passen. Und der Script-Genehmigungsmechanismus macht es produktionsreif für Umgebungen, in denen ihr diesen menschlichen Checkpoint braucht.

Schaut euch die Original-Ankündigung an, die Agent Skills Dokumentation auf Microsoft Learn und die .NET-Beispiele auf GitHub zum Loslegen.

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.

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

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

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

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

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

Was Git-APE tatsächlich macht

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

Hier ist das Setup:

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

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

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

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

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

Warum das wichtig ist

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

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

Das Aufräumen ist genauso einfach:

@git-ape destroy my-resource-group

Meine Einschätzung

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

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

Zusammenfassung

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

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

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

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

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

Wenn du jemals versucht hast, zwei Instanzen desselben Projekts gleichzeitig zu starten, kennst du den Schmerz. Port 8080 wird bereits verwendet. Port 17370 ist belegt. Etwas killen, neustarten, Umgebungsvariablen jonglieren — ein echter Produktivitätskiller.

Dieses Problem wird schlimmer, nicht besser. KI-Agenten erstellen Git Worktrees um unabhängig zu arbeiten. Hintergrund-Agenten starten separate Umgebungen. Entwickler checken dasselbe Repo zweimal für Feature-Branches aus. Jedes dieser Szenarien läuft gegen dieselbe Wand: Zwei Instanzen derselben App kämpfen um dieselben Ports.

Aspire 13.2 behebt das mit einem einzigen Flag. James Newton-King vom Aspire-Team hat alle Details aufgeschrieben, und es ist eines dieser „warum hatten wir das nicht schon früher"-Features.

Die Lösung: `--isolated`

aspire run --isolated

Das war’s. Jeder Lauf bekommt:

Zufällige Ports — keine Kollisionen mehr zwischen Instanzen
Isolierte User Secrets — Connection Strings und API Keys bleiben pro Instanz getrennt

Keine manuelle Port-Neuzuweisung. Kein Umgebungsvariablen-Jonglieren. Jeder Lauf bekommt automatisch eine frische, kollisionsfreie Umgebung.

Reale Szenarien, in denen das glänzt

Mehrere Checkouts. Du hast einen Feature-Branch in einem Verzeichnis und einen Bugfix in einem anderen:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Beide laufen ohne Konflikte. Das Dashboard zeigt, was wo läuft.

Hintergrund-Agenten in VS Code. Wenn der Hintergrund-Agent von Copilot Chat einen Git Worktree erstellt um unabhängig an deinem Code zu arbeiten, muss er möglicherweise deinen Aspire AppHost starten. Ohne --isolated ist das ein Port-Konflikt mit deinem primären Worktree. Mit ihm funktionieren einfach beide Instanzen.

Der Aspire-Skill, der mit aspire agent init mitkommt, weist Agenten automatisch an, --isolated zu verwenden, wenn sie in Worktrees arbeiten. So sollte Copilots Hintergrund-Agent das von Haus aus richtig handhaben.

Integrationstests parallel zur Entwicklung. Tests gegen einen laufenden AppHost ausführen während du weiter Features baust? Der isolierte Modus gibt jedem Kontext eigene Ports und Konfiguration.

Wie es unter der Haube funktioniert

Wenn du --isolated übergibst, generiert die CLI eine eindeutige Instanz-ID für den Lauf. Das treibt zwei Verhaltensweisen:

Port-Randomisierung — statt sich an vorhersagbare Ports aus deiner AppHost-Konfiguration zu binden, wählt der isolierte Modus zufällige verfügbare Ports für alles — das Dashboard, Service-Endpoints, alles. Service Discovery passt sich automatisch an, sodass sich Services gegenseitig finden, unabhängig davon, auf welchen Ports sie landen.
Secret-Isolation — jeder isolierte Lauf bekommt seinen eigenen User-Secrets-Speicher, der durch die Instanz-ID identifiziert wird. Connection Strings und API Keys eines Laufs lecken nicht in einen anderen.

Dein Code braucht keine Änderungen. Aspires Service Discovery löst Endpoints zur Laufzeit auf, sodass alles korrekt verbunden wird, unabhängig von der Port-Zuweisung.

Wann man es verwenden sollte

Verwende --isolated, wenn du mehrere Instanzen desselben AppHosts gleichzeitig betreibst — sei es für parallele Entwicklung, automatisierte Tests, KI-Agenten oder Git Worktrees. Für Einzelinstanz-Entwicklung, bei der du vorhersagbare Ports bevorzugst, funktioniert das reguläre aspire run weiterhin bestens.

Zusammenfassung

Der isolierte Modus ist ein kleines Feature, das ein reales, zunehmend häufiges Problem löst. Da KI-gestützte Entwicklung uns in Richtung mehr paralleler Workflows drängt — mehrere Agenten, mehrere Worktrees, mehrere Kontexte — ist die Fähigkeit, einfach eine weitere Instanz hochzufahren ohne um Ports zu kämpfen, essentiell.

Lies den vollständigen Post für alle technischen Details und probiere es aus mit aspire update --self um Version 13.2 zu bekommen.

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

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

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

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

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

Die Einstellung

Tools > Options > Environment > Windows > Floating Windows

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

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

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

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

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

Schnelle Empfehlungen

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

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

Fazit

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

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

Echtzeit-Multi-Agent-UIs Bauen, Die Sich Nicht Wie eine Black Box Anfühlen

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

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

Hier ist das Ding mit Multi-Agent-Systemen: Sie sehen in Demos unglaublich aus. Drei Agenten, die Arbeit weiterreichen, Probleme lösen, Entscheidungen treffen. Dann versuchst du es echten Benutzern zu zeigen und… Stille. Ein drehender Ladeindikator. Keine Ahnung, welcher Agent was macht oder warum das System pausiert ist. Das ist kein Produkt — das ist ein Vertrauensproblem.

Das Microsoft Agent Framework Team hat gerade einen fantastischen Walkthrough veröffentlicht, wie man MAF-Workflows mit AG-UI kombiniert — einem offenen Protokoll zum Streamen von Agent-Ausführungsereignissen an ein Frontend über Server-Sent Events. Und ehrlich gesagt? Das ist genau die Brücke, die uns gefehlt hat.

Warum das für .NET-Entwickler wichtig ist

Wenn du KI-gestützte Apps baust, bist du wahrscheinlich schon an diese Wand gestoßen. Deine Backend-Orchestrierung funktioniert super — Agenten übergeben aneinander, Tools feuern, Entscheidungen werden getroffen. Aber das Frontend hat keine Ahnung, was hinter den Kulissen passiert. AG-UI löst das, indem es ein Standardprotokoll zum Streamen von Agent-Events definiert (denk an RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) direkt an deine UI-Schicht über SSE.

Die Demo ist ein Kundenservice-Workflow mit drei Agenten: ein Triage-Agent, der Anfragen weiterleitet, ein Erstattungs-Agent für Geldangelegenheiten, und ein Bestell-Agent für Austauschvorgänge. Jeder Agent hat seine eigenen Tools, und die Handoff-Topologie ist explizit definiert — kein “finde es aus dem Prompt heraus”-Vibe.

Die Handoff-Topologie ist der eigentliche Star

Was mir aufgefallen ist, ist wie HandoffBuilder dir erlaubt, einen gerichteten Routing-Graphen zwischen Agenten zu deklarieren:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Jedes add_handoff erstellt eine gerichtete Kante mit einer natürlichsprachlichen Beschreibung. Das Framework generiert Handoff-Tools für jeden Agenten basierend auf dieser Topologie. Routing-Entscheidungen basieren also auf deiner Orchestrierungsstruktur, nicht nur darauf, was das LLM gerade für richtig hält. Das ist ein riesiger Gewinn für die Produktionszuverlässigkeit.

Human-in-the-Loop, das tatsächlich funktioniert

Die Demo zeigt zwei Unterbrechungsmuster, die jede echte Agent-App braucht:

Tool-Genehmigungs-Unterbrechungen — wenn ein Agent ein Tool aufruft, das mit approval_mode="always_require" markiert ist, pausiert der Workflow und sendet ein Event. Das Frontend rendert ein Genehmigungs-Modal mit dem Tool-Namen und den Argumenten. Keine Token-verbrennenden Retry-Schleifen — einfach ein sauberer Pause-Genehmigung-Fortsetzen-Ablauf.

Informationsanfrage-Unterbrechungen — wenn ein Agent mehr Kontext vom Benutzer braucht (wie eine Bestell-ID), pausiert er und fragt nach. Das Frontend zeigt die Frage an, der Benutzer antwortet, und die Ausführung wird genau dort fortgesetzt, wo sie aufgehört hat.

Beide Muster werden als Standard-AG-UI-Events gestreamt, sodass dein Frontend keine agenten-spezifische Logik braucht — es rendert einfach jedes Event, das über die SSE-Verbindung kommt.

Die Anbindung ist überraschend einfach

Die Integration zwischen MAF und AG-UI ist ein einziger Funktionsaufruf:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

Die workflow_factory erstellt einen frischen Workflow pro Thread, sodass jede Konversation isolierten State bekommt. Der Endpoint übernimmt die gesamte SSE-Verkabelung automatisch. Wenn du bereits FastAPI nutzt (oder es als leichte Schicht hinzufügen kannst), ist das praktisch ohne Reibungsverluste.

Meine Einschätzung

Für uns .NET-Entwickler ist die sofortige Frage: „Geht das auch in C#?" Das Agent Framework ist für .NET und Python verfügbar, und das AG-UI-Protokoll ist sprachunabhängig (es ist nur SSE). Obwohl diese spezifische Demo Python und FastAPI verwendet, lässt sich das Muster direkt übertragen. Du könntest eine ASP.NET Core Minimal API mit SSE-Endpoints nach dem gleichen AG-UI-Event-Schema aufbauen.

Die wichtigere Erkenntnis ist, dass Multi-Agent-UIs zu einem erstklassigen Thema werden — nicht mehr nur ein Nachgedanke. Wenn du irgendetwas baust, wo Agenten mit Menschen interagieren — Kundenservice, Genehmigungs-Workflows, Dokumentenverarbeitung — dann ist diese Kombination aus MAF-Orchestrierung und AG-UI-Transparenz das Muster, dem man folgen sollte.

Zusammenfassung

AG-UI + Microsoft Agent Framework gibt dir das Beste aus beiden Welten: robuste Multi-Agent-Orchestrierung im Backend und Echtzeit-Transparenz im Frontend. Keine Black-Box-Agent-Interaktionen mehr.

Schau dir den vollständigen Walkthrough und das AG-UI-Protokoll-Repository an, um tiefer einzutauchen.

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.

Microsoft Foundry März 2026 — GPT-5.4, Agent Service GA und das SDK-Refresh, das Alles Verändert

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

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

Die monatlichen „What’s New in Microsoft Foundry"-Posts sind normalerweise eine Mischung aus inkrementellen Verbesserungen und gelegentlichen Highlight-Features. Die März 2026-Ausgabe? Praktisch nur Highlight-Features. Foundry Agent Service erreicht GA, GPT-5.4 geht in Produktion, das SDK bekommt ein großes stabiles Release, und Fireworks AI bringt Open-Model-Inferenz nach Azure. Schauen wir uns an, was für .NET-Entwickler wichtig ist.

Foundry Agent Service ist produktionsreif

Das ist die große Neuigkeit. Die Runtime der nächsten Generation für Agenten ist allgemein verfügbar — aufgebaut auf der OpenAI Responses API, draht-kompatibel mit OpenAI-Agenten und offen für Modelle verschiedener Anbieter. Wenn ihr heute mit der Responses API baut, fügt die Migration zu Foundry Enterprise-Sicherheit, privates Networking, Entra RBAC, vollständiges Tracing und Evaluation auf eure bestehende Agentenlogik hinzu.

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

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

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.",
 ),
)

Zentrale Neuerungen: End-to-End Private Networking, MCP-Auth-Erweiterung (einschließlich OAuth-Passthrough), Voice Live Preview für Sprach-zu-Sprach-Agenten und gehostete Agenten in 6 neuen Regionen.

GPT-5.4 — Zuverlässigkeit über reine Intelligenz

Bei GPT-5.4 geht es nicht darum, schlauer zu sein. Es geht um Zuverlässigkeit. Stärkeres Reasoning über lange Interaktionen, bessere Instruktionstreue, weniger Ausfälle mitten im Workflow und integrierte Computer-Use-Fähigkeiten. Für Produktions-Agenten ist diese Zuverlässigkeit viel wichtiger als Benchmark-Scores.

Modell	Preis (pro M Token)	Ideal für
GPT-5.4 (≤272K)	$2.50 / $15 Output	Produktions-Agenten, Coding, Dokumenten-Workflows
GPT-5.4 Pro	$30 / $180 Output	Tiefgehende Analyse, wissenschaftliches Reasoning
GPT-5.4 Mini	Kostengünstig	Klassifikation, Extraktion, leichte Tool-Aufrufe

Die clevere Strategie ist Routing: GPT-5.4 Mini übernimmt die hochvolumige, latenzarme Arbeit, während GPT-5.4 die reasoning-intensiven Anfragen bearbeitet.

Das SDK ist endlich stabil

Das azure-ai-projects SDK hat stabile Releases in allen Sprachen veröffentlicht — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0 und .NET 2.0.0 (1. April). Die azure-ai-agents-Abhängigkeit ist weg — alles lebt unter AIProjectClient. Installation mit pip install azure-ai-projects, das Paket bündelt openai und azure-identity als direkte Abhängigkeiten.

Für .NET-Entwickler bedeutet das ein einziges NuGet-Paket für die gesamte Foundry-Oberfläche. Schluss mit dem Jonglieren separater Agent-SDKs.

Fireworks AI bringt offene Modelle nach Azure

Vielleicht die architektonisch interessanteste Ergänzung: Fireworks AI verarbeitet über 13 Billionen Token täglich bei ~180K Anfragen/Sekunde, jetzt über Foundry verfügbar. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5 und MiniMax M2.5 zum Start.

Die eigentliche Geschichte ist Bring-Your-Own-Weights — quantisierte oder feingetunete Gewichte von überall hochladen, ohne den Serving-Stack zu ändern. Deployment über serverloses Pay-per-Token oder provisionierten Durchsatz.

Weitere Highlights

Phi-4 Reasoning Vision 15B — multimodales Reasoning für Charts, Diagramme und Dokumentlayouts
Evaluations GA — fertige Evaluatoren mit kontinuierlichem Produktions-Monitoring direkt in Azure Monitor
Priority Processing (Preview) — dedizierte Compute-Lane für latenzempfindliche Workloads
Voice Live — Sprach-zu-Sprach-Runtime, die direkt mit Foundry-Agenten verbunden ist
Tracing GA — End-to-End-Inspektion von Agenten-Traces mit Sortierung und Filterung
PromptFlow-Deprecation — Migration zu Microsoft Framework Workflows bis Januar 2027

Fazit

März 2026 ist ein Wendepunkt für Foundry. Agent Service GA, stabile SDKs in allen Sprachen, GPT-5.4 für zuverlässige Produktions-Agenten und Open-Model-Inferenz über Fireworks AI — die Plattform ist bereit für ernsthafte Workloads.

Lest den vollständigen Überblick und baut euren ersten Agenten, um loszulegen.

SQL MCP Server — Der richtige Weg, AI-Agenten Datenbankzugriff zu geben

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

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

Seien wir ehrlich: Die meisten heute verfügbaren Datenbank-MCP-Server sind beängstigend. Sie nehmen eine natürlichsprachliche Abfrage, generieren SQL im laufenden Betrieb und führen es gegen Ihre Produktionsdaten aus. Was könnte schiefgehen? (Alles. Alles könnte schiefgehen.)

Das Azure SQL-Team hat gerade den SQL MCP Server vorgestellt, und er verfolgt einen grundlegend anderen Ansatz. Als Feature von Data API builder (DAB) 2.0 gebaut, gibt er AI-Agenten strukturierten, deterministischen Zugriff auf Datenbankoperationen — ohne NL2SQL, ohne Schema-Exposition und mit vollständigem RBAC bei jedem Schritt.

Warum kein NL2SQL?

Das ist die interessanteste Design-Entscheidung. Modelle sind nicht deterministisch, und komplexe Abfragen produzieren am wahrscheinlichsten subtile Fehler. Genau die Abfragen, von denen Benutzer hoffen, dass AI sie generieren kann, sind auch diejenigen, die die meiste Prüfung erfordern, wenn sie nicht-deterministisch erzeugt werden.

Stattdessen verwendet SQL MCP Server einen NL2DAB-Ansatz. Der Agent arbeitet mit der Entitäts-Abstraktionsschicht von Data API builder und dem integrierten Query Builder, um akkurates, wohlgeformtes T-SQL deterministisch zu produzieren. Gleiches Ergebnis für den Benutzer, aber ohne das Risiko halluzinierter JOINs oder versehentlicher Datenexposition.

Sieben Tools, nicht siebenhundert

SQL MCP Server exponiert genau sieben DML-Tools, unabhängig von der Datenbankgröße:

describe_entities — verfügbare Entitäten und Operationen entdecken
create_record — Zeilen einfügen
read_records — Tabellen und Views abfragen
update_record — Zeilen ändern
delete_record — Zeilen entfernen
execute_entity — gespeicherte Prozeduren ausführen
aggregate_records — Aggregationsabfragen

Das ist clever, weil Context Windows der Denkraum des Agenten sind. Sie mit Hunderten von Tool-Definitionen zu überfluten lässt weniger Raum für das Denken. Sieben feste Tools halten den Agenten auf Denken statt Navigieren fokussiert.

Jedes Tool kann einzeln aktiviert oder deaktiviert werden:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

In drei Befehlen starten

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Das ist ein laufender SQL MCP Server, der Ihre Customers-Tabelle exponiert. Die Entitäts-Abstraktionsschicht bedeutet, dass Sie Namen und Spalten aliasieren, Felder pro Rolle beschränken und genau kontrollieren können, was Agenten sehen — ohne interne Schema-Details preiszugeben.

Die Sicherheitsgeschichte überzeugt

Hier zahlt sich die Reife von Data API builder aus:

RBAC auf jeder Ebene — jede Entität definiert, welche Rollen lesen, erstellen, aktualisieren oder löschen können, und welche Felder sichtbar sind
Azure Key Vault-Integration — Connection Strings und Secrets sicher verwaltet
Microsoft Entra + Custom OAuth — Authentifizierung auf Produktionsniveau
Content Security Policy — Agenten interagieren über einen kontrollierten Vertrag, nicht über rohes SQL

Die Schema-Abstraktion ist besonders wichtig. Ihre internen Tabellen- und Spaltennamen werden niemals dem Agenten exponiert. Sie definieren Entitäten, Aliase und Beschreibungen, die für die AI-Interaktion sinnvoll sind — nicht Ihr Datenbank-ERD.

Multi-Datenbank und Multi-Protokoll

SQL MCP Server unterstützt Microsoft SQL, PostgreSQL, Azure Cosmos DB und MySQL. Und da es ein DAB-Feature ist, bekommen Sie REST-, GraphQL- und MCP-Endpoints gleichzeitig aus derselben Konfiguration. Gleiche Entitätsdefinitionen, gleiche RBAC-Regeln, gleiche Sicherheit — über alle drei Protokolle.

Die Auto-Konfiguration in DAB 2.0 kann sogar Ihre Datenbank inspizieren und die Konfiguration dynamisch aufbauen, wenn Sie für schnelles Prototyping mit weniger Abstraktion arbeiten möchten.

Meine Einschätzung

So sollte Enterprise-Datenbankzugriff für AI-Agenten funktionieren. Nicht „Hey LLM, schreib mir SQL und YOLO es gegen Produktion." Stattdessen: eine wohldefinierte Entitätsschicht, deterministische Abfragegenerierung, RBAC bei jedem Schritt, Caching, Monitoring und Telemetrie. Es ist langweilig auf die bestmögliche Art.

Für .NET-Entwickler ist die Integrationsgeschichte sauber — DAB ist ein .NET-Tool, der MCP Server läuft als Container, und er funktioniert mit Azure SQL, das die meisten von uns bereits verwenden. Wenn Sie AI-Agenten bauen, die Datenzugriff brauchen, starten Sie hier.

Zusammenfassung

SQL MCP Server ist kostenlos, Open Source und läuft überall. Es ist der präskriptive Ansatz von Microsoft, um AI-Agenten sicheren Datenbankzugriff zu geben. Lesen Sie den vollständigen Beitrag und die Dokumentation für den Einstieg.

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.

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

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

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

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

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

Verbesserungen der Agents App

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

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

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

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

CSS `@import` Link-Auflösung

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

Fazit

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

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

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

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

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

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

Lass mich hervorheben, was wirklich wissenswert ist.

Hintergrund-Terminals kommunizieren mit Agenten

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

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

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

SSH-Remote-Agent-Hosting

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

Edit-Tracking in Agent-Sitzungen

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

Browser-Tab-Erkennung und weitere Verbesserungen

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

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

Fazit

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

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

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.

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

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

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

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

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

Was sich geändert hat

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

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

Warum das wichtiger ist als es klingt

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

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

Rollout-Status

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

Zusammenfassung

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

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

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

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

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

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

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

Der Bookmark Manager

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

Organisation mit Labels, Farben und Ordnern

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

Exportieren und Teilen

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

Bookmarks die dem Code folgen

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

Zusammenfassung

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

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.

SQL MCP Server, Copilot in SSMS und ein Database Hub mit KI-Agenten: Was von der SQLCon 2026 wirklich zählt

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft hat gerade die SQLCon 2026 zusammen mit der FabCon in Atlanta eröffnet, und es gibt eine Menge zu besprechen. Die ursprüngliche Ankündigung deckt alles ab, von Sparplänen bis hin zu Enterprise-Compliance-Features. Ich werde die Enterprise-Preisfolien überspringen und mich auf die Dinge konzentrieren, die wichtig sind, wenn du als Entwickler mit Azure SQL und KI arbeitest.

SQL MCP Server ist in der Public Preview

Das ist für mich die Hauptnachricht. Azure SQL Database Hyperscale hat jetzt einen SQL MCP Server in der Public Preview, mit dem du deine SQL-Daten sicher mit KI-Agenten und Copilots über das Model Context Protocol verbinden kannst.

Wenn du die MCP-Welle verfolgt hast — und ehrlich gesagt, man kann sie gerade kaum übersehen — dann ist das eine große Sache. Statt eigene Datenpipelines zu bauen, um deinen KI-Agenten Kontext aus der Datenbank zu liefern, bekommst du ein standardisiertes Protokoll, um SQL-Daten direkt zur Verfügung zu stellen. Deine Agenten können live Datenbankinformationen abfragen, darüber nachdenken und darauf reagieren.

Für diejenigen von uns, die KI-Agenten mit Semantic Kernel oder dem Microsoft Agent Framework bauen, eröffnet das einen sauberen Integrationspfad. Dein Agent muss den Lagerbestand prüfen? Einen Kundendatensatz nachschlagen? Eine Bestellung validieren? MCP gibt ihm einen strukturierten Weg, das zu tun, ohne dass du für jedes Szenario maßgeschneiderten Datenabruf-Code schreiben musst.

GitHub Copilot in SSMS 22 ist jetzt GA

Wenn du Zeit in SQL Server Management Studio verbringst — und seien wir ehrlich, die meisten von uns tun das immer noch — GitHub Copilot ist jetzt in SSMS 22 allgemein verfügbar. Dieselbe Copilot-Erfahrung, die du bereits in VS Code und Visual Studio nutzt, aber für T-SQL.

Der praktische Nutzen ist klar: Chat-basierte Unterstützung beim Schreiben von Abfragen, Refactoring von Stored Procedures, Fehlerbehebung bei Performance-Problemen und Verwaltungsaufgaben. Konzeptionell nichts Revolutionäres, aber es direkt in SSMS zu haben bedeutet, dass du nicht zu einem anderen Editor wechseln musst, nur um KI-Hilfe für deine Datenbankarbeit zu bekommen.

Vector Indexes haben ein ernsthaftes Upgrade bekommen

Azure SQL Database hat jetzt schnellere, leistungsfähigere Vector Indexes mit voller Unterstützung für Insert, Update und Delete. Das bedeutet, deine Vektordaten bleiben in Echtzeit aktuell — kein Batch-Reindexing mehr nötig.

Das ist neu:

Quantisierung für kleinere Indexgrößen ohne zu viel Genauigkeit zu verlieren
Iteratives Filtering für präzisere Ergebnisse
Engere Integration mit dem Query Optimizer für vorhersagbare Performance

Wenn du Retrieval-Augmented Generation (RAG) mit Azure SQL als Vector Store machst, sind diese Verbesserungen direkt nützlich. Du kannst deine Vektoren zusammen mit deinen relationalen Daten in derselben Datenbank halten, was deine Architektur im Vergleich zum Betrieb einer separaten Vektordatenbank erheblich vereinfacht.

Dieselben Vektor-Verbesserungen sind auch in SQL Database in Fabric verfügbar, da beide unter der Haube auf derselben SQL-Engine laufen.

Database Hub in Fabric: Agentisches Management

Dieser Punkt ist eher zukunftsorientiert, aber er ist interessant. Microsoft hat den Database Hub in Microsoft Fabric (Early Access) angekündigt, der dir eine einheitliche Ansicht über Azure SQL, Cosmos DB, PostgreSQL, MySQL und SQL Server via Arc bietet.

Der interessante Aspekt ist nicht nur die einheitliche Ansicht — es ist der agentische Ansatz beim Management. KI-Agenten überwachen kontinuierlich dein Datenbankökosystem, zeigen auf, was sich geändert hat, erklären, warum es wichtig ist, und schlagen vor, was als nächstes zu tun ist. Es ist ein Human-in-the-Loop-Modell, bei dem der Agent die Vorarbeit leistet und du die Entscheidungen triffst.

Für Teams, die mehr als eine Handvoll Datenbanken verwalten, könnte das den operativen Lärm wirklich reduzieren. Statt zwischen Portalen zu wechseln und manuell Metriken zu prüfen, bringt der Agent das Signal zu dir.

Was das für .NET-Entwickler bedeutet

Der rote Faden, der all diese Ankündigungen verbindet, ist klar: Microsoft bettet KI-Agenten in jede Schicht des Datenbank-Stacks ein. Nicht als Spielerei, sondern als praktische Werkzeugebene.

Wenn du .NET-Apps baust, die auf Azure SQL basieren, hier ist, was ich tatsächlich tun würde:

Probier den SQL MCP Server aus, wenn du KI-Agenten baust. Es ist der sauberste Weg, deinen Agenten Datenbankzugriff zu geben, ohne eigene Plumbing zu bauen.
Aktiviere Copilot in SSMS, falls du es noch nicht getan hast — ein kostenloser Produktivitätsgewinn für die tägliche SQL-Arbeit.
Schau dir Vector Indexes an, wenn du RAG machst und derzeit einen separaten Vector Store betreibst. Die Konsolidierung auf Azure SQL bedeutet einen Service weniger zu verwalten.

Zusammenfassung

Die vollständige Ankündigung enthält mehr — Sparpläne, Migrationsassistenten, Compliance-Features — aber die Developer-Story liegt im MCP Server, den Vektor-Verbesserungen und der agentischen Management-Schicht. Das sind die Dinge, die verändern, wie du baust, nicht nur wie du budgetierst.

Schau dir die vollständige Ankündigung von Shireesh Thota für das komplette Bild an, und melde dich für den Database Hub Early Access an, wenn du die neue Management-Erfahrung ausprobieren möchtest.

Azure DevOps MCP Server landet in Microsoft Foundry: Was das für deine KI-Agenten bedeutet

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

MCP (Model Context Protocol) hat gerade seinen Moment. Wenn du das KI-Agenten-Ökosystem verfolgst, hast du wahrscheinlich bemerkt, dass MCP-Server überall auftauchen — sie geben Agenten die Fähigkeit, über ein standardisiertes Protokoll mit externen Tools und Diensten zu interagieren.

Jetzt ist der Azure DevOps MCP Server in Microsoft Foundry verfügbar, und das ist eine dieser Integrationen, die einen über die praktischen Möglichkeiten nachdenken lässt.

Was hier tatsächlich passiert

Microsoft hat den Azure DevOps MCP Server bereits als Public Preview veröffentlicht — das ist der MCP-Server selbst. Neu ist die Foundry-Integration. Du kannst den Azure DevOps MCP Server jetzt direkt aus dem Tool-Katalog zu deinen Foundry-Agenten hinzufügen.

Für diejenigen, die Foundry noch nicht kennen: Es ist Microsofts einheitliche Plattform zum Erstellen und Verwalten von KI-gestützten Anwendungen und Agenten im großen Maßstab. Modellzugriff, Orchestrierung, Evaluierung, Deployment — alles an einem Ort.

Die Einrichtung

Die Einrichtung ist überraschend unkompliziert:

Gehe in deinem Foundry-Agenten zu Add Tools > Catalog
Suche nach “Azure DevOps”
Wähle den Azure DevOps MCP Server (Preview) und klicke auf Create
Gib deinen Organisationsnamen ein und verbinde

Das war’s. Dein Agent hat jetzt Zugriff auf Azure DevOps-Tools.

Kontrollieren, worauf dein Agent zugreifen kann

Das ist der Teil, den ich schätze: Du bist nicht auf einen Alles-oder-Nichts-Ansatz festgelegt. Du kannst festlegen, welche Tools deinem Agenten zur Verfügung stehen. Wenn du also willst, dass er nur Work Items lesen, aber keine Pipelines anfassen darf, kannst du das konfigurieren. Prinzip der minimalen Berechtigung, angewandt auf deine KI-Agenten.

Das ist wichtig für Enterprise-Szenarien, in denen du nicht willst, dass ein Agent versehentlich eine Deployment-Pipeline auslöst, weil jemand ihn gebeten hat, “beim Release zu helfen.”

Warum das für .NET-Teams interessant ist

Denk darüber nach, was das in der Praxis ermöglicht:

Sprint-Planungsassistenten — Agenten, die Work Items abrufen, Velocity-Daten analysieren und Sprint-Kapazität vorschlagen können
Code-Review-Bots — Agenten, die deinen PR-Kontext verstehen, weil sie tatsächlich deine Repos und verknüpften Work Items lesen können
Incident Response — Agenten, die Work Items erstellen, kürzliche Deployments abfragen und Bugs mit kürzlichen Änderungen korrelieren können
Entwickler-Onboarding — “Woran sollte ich arbeiten?” bekommt eine echte Antwort, gestützt auf tatsächliche Projektdaten

Für .NET-Teams, die Azure DevOps bereits für ihre CI/CD-Pipelines und Projektverwaltung nutzen, ist ein KI-Agent, der direkt mit diesen Systemen interagieren kann, ein bedeutender Schritt in Richtung nützlicher Automatisierung.

Das größere MCP-Bild

Das ist Teil eines breiteren Trends: MCP-Server werden zum Standard, wie KI-Agenten mit der Außenwelt interagieren. Wir sehen sie für GitHub, Azure DevOps, Datenbanken, SaaS-APIs — und Foundry wird zum Hub, wo all diese Verbindungen zusammenkommen.

Wenn du Agenten im .NET-Ökosystem baust, lohnt es sich, MCP im Auge zu behalten. Das Protokoll ist standardisiert, das Tooling reift heran, und die Foundry-Integration macht es zugänglich, ohne Server-Verbindungen manuell einrichten zu müssen.

Zusammenfassung

Der Azure DevOps MCP Server in Foundry ist in der Preview, also rechne damit, dass er sich weiterentwickelt. Aber der Kern-Workflow ist solide: verbinden, Tool-Zugriff konfigurieren und deine Agenten mit deinen DevOps-Daten arbeiten lassen. Wenn du bereits im Foundry-Ökosystem bist, ist das nur ein paar Klicks entfernt. Probier es aus und schau, welche Workflows du bauen kannst.

Schau dir die vollständige Ankündigung für die Schritt-für-Schritt-Einrichtung und weitere Details an.

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.

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

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

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

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

Der neue `azd ai agent` Workflow

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

azd ai agent init
azd up

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

Was unter der Haube passiert

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

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

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

Die innere Entwicklungsschleife

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

azd ai agent run

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

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

Echtzeit-Monitoring

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

azd ai agent monitor --follow

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

Der komplette Befehlssatz

Hier die Kurzreferenz:

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

Warum das für .NET-Entwickler wichtig ist

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

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

Zusammenfassung

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

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.

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

Schreibe für The .NET Blog

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog ist eine community-getriebene Publikation, in der Entwickler Einblicke, Tutorials und Geschichten rund um .NET, Azure, KI und Cloud-native-Entwicklung teilen. Wir begrüßen Beiträge von Entwicklern aller Erfahrungsstufen — egal ob du deinen ersten technischen Artikel schreibst oder ein erfahrener Speaker bist.

So machst du mit

Alles liegt auf GitHub und folgt einem Pull-Request-Workflow. So legst du los:

1. Repository forken

Gehe zu github.com/thedotnetblog/blog und forke das Repository in deinen GitHub-Account.

2. Autorenprofil anlegen

Wenn du zum ersten Mal beiträgst, füge dich als Autor hinzu, indem du einen Ordner unter content/authors/dein-benutzername/ mit einer index.md-Datei erstellst:

---
title: "Dein Name"
id: "dein-benutzername"
role: "Deine Rolle oder Position"
bio: "Eine kurze Biografie über dich."
avatar: "/img/authors/dein-avatar.jpg"
socials:
 - platform: "GitHub"
 url: "https://github.com/dein-benutzername"
 - platform: "Twitter"
 url: "https://x.com/dein-benutzername"
---

Füge dein Avatar-Bild (quadratisch, mindestens 200×200px) unter static/img/authors/ hinzu.

3. Beitrag schreiben

Erstelle einen neuen Ordner unter content/posts/dein-benutzername/dein-beitrag-slug/ und füge eine index.md-Datei hinzu:

---
title: "Titel deines Beitrags"
date: 2025-01-01
author: "dein-benutzername"
description: "Eine kurze Beschreibung deines Beitrags."
tags: ["dotnet", "azure"]
---

Inhalt deines Beitrags in Markdown...

4. Pull Request öffnen

Pushe deine Änderungen in deinen Fork und öffne einen Pull Request gegen den main-Branch. Unser Team wird ihn reviewen und innerhalb weniger Tage Feedback geben.

Was wir suchen

Tutorials — Schritt-für-Schritt-Anleitungen zu .NET, Azure, KI, Blazor, Aspire und mehr
Tiefgehende Analysen — ausführliche Erkundungen einer Technologie, eines Musters oder einer Architektur
Community-Geschichten — deine Erfahrungen beim Bauen mit .NET in der Produktion
Event-Zusammenfassungen — Berichte von Konferenzen, Meetups oder Webinaren

Richtlinien

Inhalte sollten technisch und für das .NET-Ökosystem relevant sein
Codebeispiele müssen korrekt und in einem echten Projekt getestet sein
Füge eine aussagekräftige Beschreibung und mindestens ein relevantes Tag hinzu
Beiträge werden automatisch in alle unterstützten Sprachen übersetzt

Kontakt

Öffne ein Issue auf GitHub oder schreib uns auf X / Twitter. Wir freuen uns, dich in der Community willkommen zu heißen!

The .NET Blog

NDC Oslo 2026

In Zahlen

Bestätigte Speaker

Tickets

Weitere NDC-Events 2026

Links

.NET Day Switzerland 2026

Das erwartet dich

Tickets

Organisatoren

Links

SDD Conference 2026

Themen

Speaker

Tickets und Infos

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

WIQL-Abfrageunterstützung

Personal Access Tokens

MCP-Annotationen

Wiki-Tool-Konsolidierung

Experimentell: MCP Apps

SQL Server 2025 als Agent-Ready Datenbank: Sicherheit, Backup und MCP in einer Engine

Ein Sicherheitsmodell für alle Datenmodelle

Einheitliches Backup = Atomare Wiederherstellung

MCP-Integration: Agenten Ohne Hand-codierten Middleware

Fazit

.NET 10 wird mit Ubuntu 26.04 LTS ausgeliefert — Was Neu Ist

.NET 10 in zwei Befehlen installieren

Container: -noble zu -resolute aktualisieren

Native AOT: 3ms Start, 1,4MB Binary

Benötigst du .NET 8 oder 9?

Azure SDK April 2026: AI Foundry 2.0 und Was .NET-Entwickler Wissen Sollten

Azure.AI.Projects 2.0.0 — Breaking Changes, die Sinn machen

Cosmos DB Java: Kritischer Sicherheitsfix (RCE)

Neue Provisioning-Bibliotheken für .NET

Fazit

CodeAct im Agent Framework: Wie du die Latenz deines Agenten halbierst

Was ist CodeAct?

Die Sicherheitskomponente: Hyperlight Micro-VMs

Einrichtung

Wann CodeAct verwenden (und wann nicht)

Jetzt ausprobieren

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

Was ist ein MCP Bundle?

Installation

Was du damit machen kannst

Erste Schritte

GPT-5.5 ist da und kommt zu Azure Foundry — Was .NET-Entwickler Wissen Müssen

Die GPT-5-Progression

Was sich wirklich geändert hat

Preise

Warum Foundry wichtig ist

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

Copilot CLI: Sitzungen bekommen echte Namen

Schneller zwischen Sitzungen wechseln

Modell-Badges im Chat

Automatische Modellauswahl in Copilot CLI

TypeScript 7.0 Nightly Opt-in

Wo Erinnert sich dein Agent an Dinge? Ein Praxisleitfaden zur Chat-Verlauf-Speicherung

Zwei grundlegende Muster

Wie Agent Framework das abstrahiert

Provider-Schnellreferenz

Wie du die Wahl triffst

Aspire 13.2: Bun-Support, bessere Container und weniger Debug-Reibung

Bun ist jetzt erstklassig

Yarn wurde zuverlässiger

Container-Verbesserungen

Explizite Pull Policy

PostgreSQL 18+ funktioniert korrekt

Debugging-Verbesserungen

Fazit

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

Die Kontextfenster-Lüge

Die Kompaktierungssteuer

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

Fazit

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

Was sind Hooks?

Wie die Erkennung funktioniert

Container: `-noble` zu `-resolute` aktualisieren