Azure Developer CLI | 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.