Azure Developer CLI | The .NET Blog

azd钩子支持Python、TypeScript和.NET：告别Shell脚本

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

本文已自动翻译。如需查看原始版本，请点击此处。

如果你曾经有一个完全用.NET构建的项目，却还需要为azd钩子编写Bash脚本，你一定懂那种痛苦。当项目其他部分都是C#时，为什么要在pre-provisioning步骤中切换到Shell语法呢？

这个问题现在有了官方解决方案。Azure Developer CLI 刚刚发布了钩子的多语言支持，效果正如预期的那么好。

什么是钩子

钩子是在azd生命周期关键节点运行的脚本——预置配置之前、部署之后等。它们在azure.yaml中定义，无需修改CLI即可注入自定义逻辑。

此前只支持Bash和PowerShell。现在可以使用Python、JavaScript、TypeScript或.NET——azd会自动处理其余的一切。

检测机制

只需将钩子指向一个文件，azd就会从文件扩展名推断语言：

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

无需额外配置。如果扩展名不明确，可以添加kind: python（或相应语言）来明确指定。

各语言的重要细节

Python

在脚本旁边（或任意父目录中）放置requirements.txt或pyproject.toml，azd会自动创建虚拟环境、安装依赖并运行脚本。

JavaScript和TypeScript

同样的模式——在脚本附近放置package.json，azd会先运行npm install。对于TypeScript，使用npx tsx，无需编译步骤，也不需要tsconfig.json。

.NET

提供两种模式：

项目模式：如果脚本旁边有.csproj文件，azd会自动运行dotnet restore和dotnet build。
单文件模式：在.NET 10+上，独立的.cs文件可通过dotnet run script.cs直接运行，无需项目文件。

执行器特定配置

每种语言都支持可选的config块：

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

对.NET开发者的意义

钩子曾是基于azd的项目中最后一个强制语言切换的地方。现在，整个部署流水线——从应用代码到基础设施脚本再到生命周期钩子——都可以使用同一种语言。你可以在钩子中复用现有的.NET工具，引用共享类库，不再需要维护Shell脚本。

总结

这看起来是个小改动，但它切实减少了日常azd工作流程中的摩擦。钩子的多语言支持现已可用——查阅官方文章获取完整文档。

azd + GitHub Copilot：AI 驱动的项目设置和智能错误修复

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

本文为自动翻译。如需阅读英文原文，请点击这里。

你是否有过这样的经历：想把现有应用部署到 Azure，却盯着空白的 azure.yaml 发呆，想不起来 Express API 到底该用 Container Apps 还是 App Service？这种时刻即将成为历史。

Azure Developer CLI（azd）现已与 GitHub Copilot 以两种实用的方式集成：azd init 时的 AI 辅助项目脚手架，以及部署失败时的智能错误排查。两项功能都完全在终端内运行——正是我想要的方式。

在 azd init 中使用 Copilot 设置

运行 azd init 时，现在会出现"Set up with GitHub Copilot (Preview)“选项。选择它，Copilot 会分析你的代码库，根据实际代码生成 azure.yaml、基础架构模板和 Bicep 模块。

azd init
# 选择："Set up with GitHub Copilot (Preview)"

前提条件：

azd 1.23.11 或更高版本 — 用 azd version 检查，或用 azd update 更新
有效的 GitHub Copilot 订阅（Individual、Business 或 Enterprise）
GitHub CLI（gh） — 必要时 azd 会提示登录

我觉得真正实用的是它能双向工作。从零开始构建？Copilot 从一开始就帮你配置正确的 Azure 服务。有现有应用想部署？把 Copilot 指向它，无需重构代码即可生成配置。

它实际做什么

假设你有一个 Node.js Express API，依赖 PostgreSQL。不必手动在 Container Apps 和 App Service 之间抉择，也不必从零编写 Bicep，Copilot 检测到你的技术栈后会生成：

包含正确 language、host 和 build 设置的 azure.yaml
Azure Container Apps 的 Bicep 模块
Azure Database for PostgreSQL 的 Bicep 模块

并在做任何更改前运行预检——验证 git 工作目录是否干净，提前请求 MCP 服务器工具的授权。一切都在你知情的情况下进行。

Copilot 驱动的错误排查

部署错误无可避免。缺少参数、权限问题、SKU 可用性问题——而错误信息很少告诉你真正需要知道的那一件事：如何修复。

没有 Copilot 时的循环：复制错误 → 搜索文档 → 读三篇不相关的 Stack Overflow 回答 → 运行一些 az CLI 命令 → 重试并祈祷。有了集成在 azd 中的 Copilot，这个循环消失了。任何 azd 命令失败时，它会立即提供四个选项：

Explain — 用通俗语言解释出了什么问题
Guidance — 逐步修复指导
Diagnose and Guide — 完整分析 + Copilot 应用修复（经你批准）+ 可选重试
Skip — 自己处理

关键在于：Copilot 已经了解你的项目、失败的命令和错误详情。它的建议针对你的具体情况，而非泛泛的文档。

设置默认行为

如果你总是选择同一个选项，可以跳过交互式提示：

azd config set copilot.errorHandling.category troubleshoot

可选值：explain、guidance、troubleshoot、fix、skip。还可以启用自动修复和重试：

azd config set copilot.errorHandling.fix allow

随时重置为交互模式：

azd config unset copilot.errorHandling.category

总结

这正是真正有价值的 Copilot 集成。运行 azd update 获取最新版本，在下一个项目中试试 azd init。

阅读原文公告。