Azd | The .NET Blog

azd Hooks in Python, TypeScript, and .NET: Stop Fighting Shell Scripts

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

If you’ve ever had a fully .NET project and still found yourself writing Bash scripts just to run azd hooks, you know the pain. Why switch to shell syntax just for a pre-provision step when everything else in your project is C#?

That frustration is now officially solved. The Azure Developer CLI just shipped multi-language hook support, and it’s exactly as good as it sounds.

Hooks, quickly, if you’re not familiar

Hooks are scripts that run at key points in the azd lifecycle — before provisioning, after deployment, and more. They’re defined in azure.yaml and let you inject custom logic without forking the CLI itself.

Previously you were limited to Bash and PowerShell. Now you can use Python, JavaScript, TypeScript, or .NET — and azd handles the rest automatically.

How the detection works

You just point the hook at a file and azd infers the language from the extension:

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

That’s it. No extra config. If the extension is ambiguous, you can add an explicit kind: python (or whatever) to override.

Language-specific details worth knowing

Python

Drop a requirements.txt or pyproject.toml next to your script (or anywhere up the directory tree) and azd creates a virtual environment, installs deps, and runs your script:

hooks/
├── setup.py
└── requirements.txt

No virtualenv management on your end. azd walks up from the script location to find the nearest project file.

JavaScript and TypeScript

Same pattern — put a package.json near your script and azd runs npm install first. For TypeScript, it uses npx tsx so there’s no compile step and no tsconfig.json required:

hooks/
├── seed.ts
└── package.json

Want to use pnpm or yarn? There’s a config.packageManager option for that.

.NET

Two modes here, which is nice:

Project mode: If there’s a .csproj next to the script, azd runs dotnet restore and dotnet build automatically.
Single-file mode: On .NET 10+, you can drop a standalone .cs file and it runs directly via dotnet run script.cs. No project file needed.

hooks:
 postprovision:
 run: ./hooks/migrate.cs

If you’re already on .NET 10, single-file mode is honestly the cleanest option for simple migration or seeding scripts. No project scaffolding, no .csproj to maintain.

Executor-specific config

Each language supports an optional config block when you need to tweak the defaults:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postdeploy:
 run: ./hooks/seed.py
 config:
 virtualEnvName: .venv
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

You can also mix formats in the same hooks: block — different languages for different lifecycle events, platform-specific overrides for Windows vs. Linux, whatever you need.

Why this matters for .NET developers

The boring answer is “consistency.” But honestly it goes deeper than that. Hooks are often the last place in an azd-based project that forces you into a different language context. Now your entire deployment pipeline — from app code to infrastructure scripts to lifecycle hooks — can live in one language.

More practically: you can now reuse your existing .NET utilities in hooks. Have a shared class library for database schema management? Just reference it in your hook project. Have a Python data-seeding script you already wrote? Drop it straight into azure.yaml.

Wrapping up

This is one of those changes that sounds small but quietly removes a lot of friction from daily azd workflows. Multi-language hook support is available now — check the official post for the full docs, and head to the azd GitHub repo to try it out on your next project.

azd + GitHub Copilot: AI-Powered Project Setup and Smarter Error Fixes

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

You know that moment when you want to deploy an existing app to Azure and suddenly find yourself staring at a blank azure.yaml, trying to remember whether your Express API should use Container Apps or App Service? Yeah, that moment. It just got a whole lot shorter.

The Azure Developer CLI (azd) now integrates with GitHub Copilot in two meaningful ways: AI-assisted project scaffolding during azd init, and intelligent error troubleshooting when deployments go sideways. Both features stay entirely in your terminal, which is exactly where I want them.

Setting Up with Copilot During azd init

When you run azd init, there’s now a “Set up with GitHub Copilot (Preview)” option. Select it and Copilot analyzes your codebase to generate the azure.yaml, infrastructure templates, and Bicep modules — based on your actual code, not a template guess.

azd init
# Select: "Set up with GitHub Copilot (Preview)"

For this to work you’ll need:

azd 1.23.11 or later — check with azd version or update with azd update
An active GitHub Copilot subscription (Individual, Business, or Enterprise)
GitHub CLI (gh) — azd will prompt for login if needed

What I find genuinely useful here is that it works both ways. Building from scratch? Copilot helps you set up the right Azure services from the start. Have an existing app you’ve been putting off deploying? Point Copilot at it and it generates the configuration without you having to restructure anything.

What it actually does

Say you have a Node.js Express API with a PostgreSQL dependency. Instead of manually figuring out whether to target Container Apps or App Service, and then writing Bicep from scratch, Copilot detects your stack and generates:

An azure.yaml with the right language, host, and build settings
A Bicep module for Azure Container Apps
A Bicep module for Azure Database for PostgreSQL

And it runs preflight checks before touching anything — verifies your git working directory is clean, asks for MCP server tool consent upfront. Nothing happens without you knowing exactly what’s about to change.

Copilot-Powered Error Troubleshooting

Deployment errors are a fact of life. Missing parameters, permission issues, SKU availability problems — and the error message rarely tells you the one thing you actually need to know: how to fix it.

Without Copilot, your loop looks like: copy the error → search docs → read through three unrelated Stack Overflow answers → run some az CLI commands → try again and hope. With Copilot integrated into azd, that loop collapses. When any azd command fails, it immediately offers four options:

Explain — plain-language description of what went wrong
Guidance — step-by-step fix instructions
Diagnose and Guide — full analysis + Copilot applies the fix (with your approval) + optional retry
Skip — handle it yourself

The key thing: Copilot already has context about your project, the command that failed, and the error output. Its suggestions are specific to your situation, not generic docs.

Real examples where this shines

Resource provider not registered:

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

This trips up anyone deploying to a fresh subscription. Copilot can register the provider and rerun the deployment automatically.

SKU not available:

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

Copilot explains which VM size or region is blocked and suggests alternatives that are actually available in your subscription.

Storage account name collision:

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

Global uniqueness bites everyone at least once. Copilot suggests adding your environment name or a random suffix to your Bicep parameters.

Set a default behavior

If you always want the same option, skip the interactive prompt:

azd config set copilot.errorHandling.category troubleshoot

Options: explain, guidance, troubleshoot, fix, skip. You can also enable auto-fix and retry:

azd config set copilot.errorHandling.fix allow

Reset to interactive at any time:

azd config unset copilot.errorHandling.category

Why this matters for .NET developers

If you’re building on Azure — whether it’s a .NET Aspire app, a containerized API, or anything in between — azd has been the tool to know for a while now. This Copilot integration removes the last bit of friction that used to make it feel like you needed a cheat sheet just to get started.

The scaffolding piece is great for brownfield projects. You’ve got an ASP.NET Core app running locally, it works perfectly, but getting it onto Azure has always required a bit of infrastructure knowledge. Now Copilot bridges that gap. And the error troubleshooting feature is something I genuinely wish I’d had the last time I spent 45 minutes debugging a SkuNotAvailable error across three regions.

Wrapping up

This is exactly the kind of Copilot integration that adds real value — not AI for AI’s sake, but AI that understands your context and saves you actual time. Try it out by running azd update to get the latest version, then use azd init on your next project. The team is working on deeper features including Copilot-assisted infrastructure customization, so now’s a good time to sign up for user research if you want to influence what comes next.

Read the original announcement here.

azd update — One Command to Rule All Your Package Managers

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

You know that “A new version of azd is available” message that pops up every few weeks? The one you dismiss because you can’t remember whether you installed azd via winget, Homebrew, or that curl script you ran six months ago? Yeah, that’s finally fixed.

Microsoft just shipped azd update — a single command that updates the Azure Developer CLI to the latest version regardless of how you originally installed it. Windows, macOS, Linux — doesn’t matter. One command.

How it works

azd update

That’s it. If you want early access to new features, you can switch to the daily insiders build:

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

The command detects your current installation method and uses the appropriate update mechanism under the hood. No more “wait, did I use winget or choco on this machine?”

The small catch

azd update ships starting with version 1.23.x. If you’re on an older version, you’ll need to do one last manual update using your original installation method. After that, azd update handles everything going forward.

Check your current version with azd version. If you need a fresh install, the install docs have you covered.

Why it matters

This is a small quality-of-life improvement, but for those of us who use azd daily for deploying AI agents and Aspire apps to Azure, staying current means fewer “this bug was already fixed in the latest version” moments. One less thing to think about.

Read the full announcement and Jon Gallant’s deeper dive for more context.

azd Now Lets You Run and Debug AI Agents Locally — Here's What Changed in March 2026

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

Seven releases in one month. That’s what the Azure Developer CLI (azd) team pushed in March 2026, and the headline feature is the one I’ve been waiting for: a local run-and-debug loop for AI agents.

PC Chan published the full roundup, and while there’s a lot in there, let me filter it down to what actually matters for .NET developers building AI-powered apps.

Run and debug AI agents without deploying

This is the big one. The new azure.ai.agents extension adds a set of commands that give you a proper inner-loop experience for AI agents:

azd ai agent run — starts your agent locally
azd ai agent invoke — sends messages to it (local or deployed)
azd ai agent show — displays container status and health
azd ai agent monitor — streams container logs in real time

Before this, testing an AI agent meant deploying to Microsoft Foundry every time you made a change. Now you can iterate locally, test your agent’s behavior, and only deploy when you’re ready. If you’ve been building agents with the Microsoft Agent Framework or Semantic Kernel, this changes your daily workflow.

The invoke command works against both local and deployed agents, which means you can use the same testing workflow regardless of where the agent is running. That’s the kind of detail that saves you from maintaining two sets of test scripts.

GitHub Copilot scaffolds your azd project

azd init now offers a “Set up with GitHub Copilot (Preview)” option. Instead of manually answering prompts about your project structure, a Copilot agent scaffolds the configuration for you. It checks for a dirty working directory before modifying anything and asks for MCP server tool consent upfront.

When a command fails, azd now offers AI-assisted troubleshooting: pick a category (explain, guidance, troubleshoot, or skip), let the agent suggest a fix, and retry — all without leaving the terminal. For complex infrastructure setups, that’s a real time saver.

Container App Jobs and deployment improvements

A few deployment features worth noting:

Container App Jobs: azd now deploys Microsoft.App/jobs through the existing host: containerapp config. Your Bicep template determines whether the target is a Container App or a Job — no extra setup.
Configurable deployment timeouts: New --timeout flag on azd deploy and a deployTimeout field in azure.yaml. No more guessing the default 1200-second limit.
Remote build fallback: When remote ACR build fails, azd falls back to local Docker/Podman build automatically.
Local preflight validation: Bicep parameters get validated locally before deploying, catching missing params without a round-trip to Azure.

Developer experience polish

Some smaller improvements that add up:

Automatic pnpm/yarn detection for JS/TS projects
pyproject.toml support for Python packaging
Local template directories — azd init --template now accepts filesystem paths for offline iteration
Better error messages in --no-prompt mode — all missing values reported at once with resolution commands
Build environment variables injected into all framework build subprocesses (.NET, Node.js, Java, Python)

That last one is subtle but important: your .NET build now has access to azd environment variables, which means you can do build-time configuration injection without extra scripting.

Wrapping up

The local AI agent debugging loop is the star of this release, but the accumulation of deployment improvements and DX polish makes azd feel more mature than ever. If you’re deploying .NET apps to Azure — especially AI agents — this update is worth the install.

Check the full release notes for every detail, or get started with azd install.

From Laptop to Production: Deploying AI Agents to Microsoft Foundry with Two Commands

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

You know that gap between “it works on my machine” and “it’s deployed and serving traffic”? For AI agents, that gap has been painfully wide. You need to provision resources, deploy models, wire up identity, set up monitoring — and that’s before anyone can actually call your agent.

The Azure Developer CLI just made this a two-command affair.

The new `azd ai agent` workflow

Let me walk through what this actually looks like. You have an AI agent project — let’s say a hotel concierge agent. It works locally. You want it running on Microsoft Foundry.

azd ai agent init
azd up

That’s it. Two commands. azd ai agent init scaffolds the infrastructure-as-code in your repo, and azd up provisions everything on Azure and publishes your agent. You get a direct link to your agent in the Foundry portal.

What happens under the hood

The init command generates real, inspectable Bicep templates in your repo:

A Foundry Resource (top-level container)
A Foundry Project (where your agent lives)
Model deployment configuration (GPT-4o, etc.)
Managed identity with proper RBAC role assignments
azure.yaml for the service map
agent.yaml with agent metadata and environment variables

Here’s the key part: you own all of this. It’s versioned Bicep in your repo. You can inspect it, customize it, and commit it alongside your agent code. No magic black boxes.

The dev inner loop

What I really like is the local development story. When you’re iterating on agent logic, you don’t want to redeploy every time you change a prompt:

azd ai agent run

This starts your agent locally. Pair it with azd ai agent invoke to send test prompts, and you’ve got a tight feedback loop. Edit code, restart, invoke, repeat.

The invoke command is smart about routing too — when a local agent is running, it targets that automatically. When it’s not, it hits the remote endpoint.

Real-time monitoring

This is the feature that sold me. Once your agent is deployed:

azd ai agent monitor --follow

Every request and response flowing through your agent streams to your terminal in real time. For debugging production issues, this is invaluable. No digging through log analytics, no waiting for metrics to aggregate — you see what’s happening right now.

The full command set

Here’s the quick reference:

Command	What it does
`azd ai agent init`	Scaffold a Foundry agent project with IaC
`azd up`	Provision Azure resources and deploy the agent
`azd ai agent invoke`	Send prompts to the remote or local agent
`azd ai agent run`	Run the agent locally for development
`azd ai agent monitor`	Stream real-time logs from the published agent
`azd ai agent show`	Check agent health and status
`azd down`	Clean up all Azure resources

Why this matters for .NET developers

Even though the sample in the announcement is Python-based, the infrastructure story is language-agnostic. Your .NET agent gets the same Bicep scaffolding, the same managed identity setup, the same monitoring pipeline. And if you’re already using azd for your .NET Aspire apps or Azure deployments, this fits right into your existing workflow.

The deployment gap for AI agents has been one of the biggest friction points in the ecosystem. Going from a working prototype to a production endpoint with proper identity, networking, and monitoring shouldn’t require a week of DevOps work. Now it requires two commands and a few minutes.

Wrapping up

azd ai agent is available now. If you’ve been putting off deploying your AI agents because the infrastructure setup felt like too much work, give this a shot. Check out the full walkthrough for the complete step-by-step including frontend chat app integration.

Azd | The .NET Blog

azd Hooks in Python, TypeScript, and .NET: Stop Fighting Shell Scripts

Hooks, quickly, if you’re not familiar

How the detection works

Language-specific details worth knowing

Python

JavaScript and TypeScript

.NET

Executor-specific config

Why this matters for .NET developers

Wrapping up

azd + GitHub Copilot: AI-Powered Project Setup and Smarter Error Fixes

Setting Up with Copilot During azd init

What it actually does

Copilot-Powered Error Troubleshooting

Real examples where this shines

Set a default behavior

Why this matters for .NET developers

Wrapping up

azd update — One Command to Rule All Your Package Managers

How it works

The small catch

Why it matters

azd Now Lets You Run and Debug AI Agents Locally — Here's What Changed in March 2026

Run and debug AI agents without deploying

GitHub Copilot scaffolds your azd project

Container App Jobs and deployment improvements

Developer experience polish

Wrapping up

From Laptop to Production: Deploying AI Agents to Microsoft Foundry with Two Commands

The new azd ai agent workflow

What happens under the hood

The dev inner loop

Real-time monitoring

The full command set

Why this matters for .NET developers

Wrapping up

The new `azd ai agent` workflow