Azd | The .NET Blog

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.

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.

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.

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.

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.

Azd | The .NET Blog

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

Was sind Hooks?

Wie die Erkennung funktioniert

Sprachspezifische Details

Python

JavaScript und TypeScript

.NET

Executor-spezifische Konfiguration

Warum das für .NET-Entwickler wichtig ist

Fazit

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

Setup mit Copilot während azd init

Was es wirklich macht

Copilot-gestützte Fehlerbehebung

Typische Fehler, bei denen das glänzt

Standardverhalten konfigurieren

Fazit

azd update — Ein Befehl für alle deine Paketmanager

So funktioniert’s

Der kleine Haken

Warum das wichtig ist

azd ermöglicht jetzt lokales Ausführen und Debuggen von KI-Agenten — Das hat sich im März 2026 geändert

KI-Agenten ausführen und debuggen ohne Deployment

GitHub Copilot richtet dein azd-Projekt ein

Container App Jobs und Deployment-Verbesserungen

DX-Verbesserungen

Zusammenfassung

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

Der neue azd ai agent Workflow

Was unter der Haube passiert

Die innere Entwicklungsschleife

Echtzeit-Monitoring

Der komplette Befehlssatz

Warum das für .NET-Entwickler wichtig ist

Zusammenfassung

Der neue `azd ai agent` Workflow