Azure SDK | The .NET Blog

Hör auf, eine kämpfende Abhängigkeit zu bombardieren: Retry-Muster für Azure Functions + Service Bus

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

So wird ein behebbarer Fehler zu einem Ausfall in einer Functions-Anwendung: Eine Abhängigkeit beginnt zu timeoutn, jede Functions-Instanz wiederholt sofort und unbegrenzt, die Abhängigkeit wird mit Hunderten gleichzeitiger fehlgeschlagener Anfragen bombardiert, und was als vorübergehender Hickup begann, wird zu einem systemweiten Gegendruck-Ereignis.

Sie kennen diese Geschichte wahrscheinlich. Azure Functions skaliert schnell — das ist der ganze Sinn. Aber “schnell skalieren” und “sofort wiederholen” zusammen können Fehler dramatisch verschlimmern.

Zwei Muster helfen. Exponential Backoff und Circuit Breaker. Beide werden jetzt nativ für Service Bus-ausgelöste Azure Functions unterstützt.

Zwei Muster, Verschiedene Rollen

Diese Muster ergänzen sich, sind keine Alternativen:

Exponential Backoff beantwortet: Wann soll ich es erneut versuchen? Es erhöht die Verzögerung zwischen Wiederholungsversuchen, damit eine Abhängigkeit Zeit hat, sich zu erholen. Auf Nachrichtenebene, Taktung des Retry-Timings.

Circuit Breaker beantwortet: Soll ich diese Abhängigkeit gerade überhaupt aufrufen? Er stoppt wiederholte Aufrufe an eine ungesunde Abhängigkeit, nachdem ein Fehlerschwellenwert erreicht wurde, und testet dann vorsichtig nach einer Abkühlungsperiode. Auf Systemebene, Verhinderung von Retry-Stürmen.

Sie wollen beide. Backoff kümmert sich um das Retry-Timing pro Nachricht. Circuit Breaker kümmert sich um aggregierte Gesundheitsentscheidungen.

Warum Das Besonders für Service Bus Wichtig Ist

Die Warteschlange absorbiert Burst-Traffic, was gut ist. Aber ohne Kontrollen kann die Warteschlange wachsen, während Worker weiterhin Rechenleistung für Aufrufe verschwenden, die fehlschlagen werden. Poison Messages bleiben länger aktiv als sie sollten. Heiße Partitionen oder begrenzte Downstream-Kapazität erzeugen Kaskadenprobleme.

Das sicherere Design:

Vorübergehenden Fehler erkennen
Den nächsten Versuch mit Exponential Backoff verzögern
Aufrufe an die Abhängigkeit stoppen, wenn ein Fehlerschwellenwert erreicht wird (Schaltkreis offen)
Nach einer Abkühlungsperiode vorsichtig fortfahren (Schaltkreis-Sonde)
Nicht wiederherstellbare Arbeit in Dead-Letter oder einen Quarantänepfad verschieben

Wie die Native Unterstützung Aussieht

Die neue Unterstützung integriert sich mit dem bestehenden Azure Functions-Host-Modell — keine zusätzlichen Bibliotheken, keine benutzerdefinierten Implementierungen. Die Konfiguration geht in Ihre host.json:

{
 "extensions": {
 "serviceBus": {
 "messageHandlerOptions": {
 "maxRetryCount": 5,
 "retryPolicy": {
 "mode": "exponentialBackoff",
 "minBackoff": "00:00:02",
 "maxBackoff": "00:05:00",
 "maxRetryCount": 5
 }
 }
 }
 }
}

Die Circuit-Breaker-Konfiguration legt den Fehlerschwellenwert und das Reset-Intervall fest, damit ungesunde Abhängigkeiten während der Wiederherstellung nicht bombardiert werden.

Abgedeckte Sprachen

Das ist nicht nur für .NET. Das Feature deckt dotnet, JavaScript, TypeScript und Python ab — den vollständigen Satz der vom Service Bus-Trigger in Azure Functions unterstützten Sprachen.

Fazit

Retry-Muster sind nicht aufregend zu konfigurieren, bis zum ersten Mal ein Downstream-Ausfall dazu führt, dass Ihre Functions das Problem verschlimmern, anstatt angemessen zu degradieren. Diese proaktiv einzurichten ist günstig. Sie während eines Incidents nachzurüsten nicht.

Originalbeitrag: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

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

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.

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.

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.