Dotnet | The .NET Blog

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 于 2026年5月11日至15日 在 伦敦 Barbican Centre 举办。为期3天的核心大会从周二到周四，周一和周五有可选的全天工作坊。

拥有 78场演讲 和 14场工作坊，是欧洲内容最丰富的开发者大会之一。

主题

架构思维
C# 13 中的函数式代码
无服务器设计
语义 AI
Azure Kubernetes Services
精益 DevOps 策略
模型上下文协议 (MCP)
.NET 中的智能代理 AI
重构单体应用
使用 LLM 更快编程
后量子世界中的密码学
本地优先开发

演讲者

世界级阵容包括 Kevlin Henney、Neal Ford、Sander Hoogendoorn、Andrew Clymer、Jacqui Read、Christian Weyer、Jeff Prosise、Jules May、Oliver Sturm 和 Raju Gandhi。

门票和信息

98%的 SDD 2025 参会者将整体体验评为"好"、“非常好"或"优秀”。

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工作流程中的摩擦。钩子的多语言支持现已可用——查阅官方文章获取完整文档。

Windows App Dev CLI v0.3：从终端实现F5调试和面向智能体的UI自动化

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

本文已自动翻译。如需查看原文，请点击这里。

Visual Studio的F5体验非常棒。但是，仅仅为了启动和调试一个打包的Windows应用而打开VS，在CI流水线、自动化工作流或AI智能体执行测试时就显得过于繁重了。

Windows App Development CLI v0.3正式发布，通过两个核心功能直接解决了这个问题：winapp run和winapp ui。

winapp run：随处可用的F5

winapp run接受一个未打包的应用文件夹和清单，执行VS在调试启动时所做的一切：注册松散包、启动应用，并在重新部署之间保留LocalState。

# 构建应用，然后作为打包应用运行
winapp run ./bin/Debug

支持WinUI、WPF、WinForms、Console、Avalonia等。各模式同时面向开发者和自动化工作流：

--detach：启动后立即将控制权返回给终端。非常适合CI/自动化。
--unregister-on-exit：应用关闭时清理已注册的包。
--debug-output：实时捕获OutputDebugString消息和异常。

新NuGet包：打包应用的dotnet run支持

面向.NET开发者，新增了一个NuGet包：Microsoft.Windows.SDK.BuildTools.WinApp。安装后，dotnet run处理整个内循环：构建、准备松散布局包、在Windows中注册和启动——一步完成。

winapp init
# 或
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui：从命令行实现UI自动化

这是开启智能体场景的功能。winapp ui从终端提供对任何正在运行的Windows应用（WPF、WinForms、Win32、Electron、WinUI3）的完整UI自动化访问。

可以实现：

列出所有顶层窗口
遍历窗口的完整UI自动化树
按名称、类型或自动化ID搜索元素
单击、调用和设置值
截图
等待元素出现——非常适合测试同步

将winapp ui与winapp run结合使用，即可从终端实现完整的构建→启动→验证工作流。智能体可以运行应用、检查UI状态、以编程方式交互并验证结果。

其他新功能

winapp unregister：测试完成后删除旁加载的包。
winapp manifest add-alias：添加别名，从终端按名称启动应用。
Tab补全：一条命令配置PowerShell补全。

安装方式

winget install Microsoft.WinAppCli
# 或
npm install -g @microsoft/winappcli

CLI处于公开预览阶段。完整文档请查看GitHub仓库，所有详细信息请查看原始公告。

别再盯着终端了：Aspire 的分离模式改变了工作流程

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

每次运行 Aspire AppHost，你的终端就没了。被锁住了。一直占用到你按 Ctrl+C 为止。需要快速运行个命令？打开另一个标签页。想查看日志？再开一个标签页。这是一种小摩擦，但积少成多。

Aspire 13.2 解决了这个问题。James Newton-King 写了完整的详情，说实话，这是那种一用就立刻改变工作方式的功能。

分离模式：一条命令，终端回来了

aspire start

这是 aspire run --detach 的简写。你的 AppHost 在后台启动，终端立即回到你手中。不需要额外的标签页。不需要终端多路复用器。就是你的提示符，随时可用。

管理正在运行的进程

关键在于——在后台运行只有在你能管理那些进程时才有用。Aspire 13.2 为此提供了一整套 CLI 命令：

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

这让 Aspire CLI 变成了一个真正的进程管理器。你可以启动多个 AppHost，检查它们的状态，跟踪日志，然后关闭它们——全部在一个终端会话中完成。

与隔离模式结合使用

分离模式与隔离模式天然搭配。想在后台运行同一个项目的两个实例而不产生端口冲突？

aspire start --isolated
aspire start --isolated

每个实例都会获得随机端口、独立的密钥和自己的生命周期。用 aspire ps 查看两者，用 aspire stop 停掉不需要的那个。

为什么这对编码代理意义重大

这才是真正有趣的地方。在你的终端中工作的编码代理现在可以：

用 aspire start 启动应用
用 aspire describe 查询状态
用 aspire logs 检查日志来诊断问题
完成后用 aspire stop 停止应用

所有操作都不会失去终端会话。在分离模式之前，运行你的 AppHost 的代理会把自己锁在终端里。现在它可以启动、观察、迭代和清理——这正是你期望自主代理的工作方式。

Aspire 团队在这方面下了功夫。运行 aspire agent init 会设置一个 Aspire 技能文件，教会代理这些命令。这样，像 Copilot 的编码代理这样的工具就能直接管理你的 Aspire 工作负载。

总结

分离模式是一个伪装成简单标志的工作流升级。你不再需要在终端之间切换上下文，代理不再阻塞自己，新的 CLI 命令让你真正看到正在运行的内容。它实用、干净，让日常开发循环明显更顺畅。

阅读完整文章了解所有详情，并通过 aspire update --self 获取 Aspire 13.2。

Pin 聚类终于登陆 .NET MAUI Maps — 一个属性，零痛苦

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

你知道那种感觉吗？在地图上加载一百个 Pin，然后整个地图变成一团看不清的东西？对，这就是 .NET MAUI Maps 一直以来的体验。现在不会了。

David Ortinau 刚刚宣布 .NET MAUI 11 Preview 3 在 Android 和 iOS/Mac Catalyst 上内置了 Pin 聚类功能。而且最棒的是 — 启用它简单得不可思议。

一个属性统治一切

<maps:Map IsClusteringEnabled="True" />

就这样。相邻的 Pin 会被分组到带有计数徽章的聚类中。放大时展开，缩小时折叠。这是用户对任何现代地图都期望的行为 — 现在你只需一个属性就能获得。

独立的聚类分组

这才是有趣的地方。不是所有 Pin 都应该聚在一起。咖啡店和公园是不同的东西，你的地图应该知道这一点。

ClusteringIdentifier 属性让你可以将 Pin 分成独立的组：

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

具有相同标识符的 Pin 会聚在一起。不同的标识符即使在地理位置很近的情况下也会形成独立的聚类。没有标识符？默认分组。干净且可预测。

处理聚类点击

当用户点击一个聚类时，你会收到一个 ClusterClicked 事件，包含你需要的一切：

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

事件参数提供 Pins（聚类中的 Pin）、Location（地理中心）和 Handled（如果你想覆盖默认缩放行为，设置为 true）。简单、实用，完全符合预期。

值得了解的平台细节

在 Android 上，聚类使用自定义的基于网格的算法，在缩放变化时重新计算 — 没有外部依赖。在 iOS 和 Mac Catalyst 上，它利用了 MapKit 原生的 MKClusterAnnotation 支持，这意味着流畅的平台原生动画。

这是 MAUI 团队做出正确决策的案例之一 — 在有意义的地方依靠平台能力。

为什么这很重要

Pin 聚类一直是 .NET MAUI 中最受期待的功能之一（issue #11811），这是有充分理由的。每个在地图上显示位置的应用 — 配送追踪、门店定位、房地产 — 都需要它。以前你必须自己构建或引入第三方库。现在它是内置的。

对于我们构建跨平台移动应用的 .NET 开发者来说，这正是那种让 MAUI 成为地图密集型场景中真正实用选择的生活质量改善。

开始使用

安装 .NET 11 Preview 3 并更新 .NET MAUI 工作负载。Maps 示例包含一个新的聚类页面，你可以立即上手体验。

去用它构建点什么吧 — 让你的地图终于能喘口气。

.NET 2026年4月服务更新 — 你今天就该应用的安全补丁

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

.NET 和 .NET Framework 的 2026年4月服务更新已发布，这次包含了你需要尽快应用的安全修复。共修补了六个CVE，其中包括两个远程代码执行（RCE）漏洞。

修补内容

快速总结如下：

CVE	类型	影响范围
CVE-2026-26171	安全功能绕过	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	远程代码执行	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	远程代码执行	.NET 10, 9, 8
CVE-2026-32203	拒绝服务	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	拒绝服务	.NET Framework 3.0–4.8.1
CVE-2026-32226	拒绝服务	.NET Framework 2.0–4.8.1

两个RCE CVE（CVE-2026-32178 和 CVE-2026-33116）影响范围最广，应当优先处理。

更新版本

.NET 10：10.0.6
.NET 9：9.0.15
.NET 8：8.0.26

均可通过常规渠道获取 — dotnet.microsoft.com、MCR上的容器镜像以及Linux包管理器。

应该怎么做

将你的项目和CI/CD管道更新到最新的补丁版本。如果你在运行容器，拉取最新的镜像。如果你在使用 .NET Framework，请查看 .NET Framework 发行说明获取对应的补丁。

对于在生产环境运行 .NET 10 的用户（这是当前版本），10.0.6 是必须更新的。.NET 9.0.15 和 .NET 8.0.26 也是如此，如果你在使用这些LTS版本的话。两个RCE漏洞可不是你能拖延的事情。

Azure MCP Server 2.0 正式发布——自托管智能云自动化来了

Emiliano Montesdeoca — Sat, 11 Apr 2026 00:00:00 +0000

本文为自动翻译。如需查看原文，请点击这里。

如果你最近一直在用 MCP 和 Azure 构建东西，你可能已经知道本地体验非常好。接入一个 MCP 服务器，让你的 AI 智能体与 Azure 资源对话，然后继续工作。但一旦你需要在团队中共享这个设置？那就会变得复杂。

不再是这样了。Azure MCP Server 刚刚发布 2.0 稳定版，而主打功能正是企业团队一直在要求的：自托管远程 MCP 服务器支持。

什么是 Azure MCP Server？

快速回顾一下。Azure MCP Server 实现了 Model Context Protocol 规范，并将 Azure 功能暴露为结构化、可发现的工具，AI 智能体可以调用。把它看作是你的智能体和 Azure 之间的标准化桥梁——配置、部署、监控、诊断，都通过一个统一的接口。

这些数字说明一切：跨越 57 个 Azure 服务的 276 个 MCP 工具。这是真正的覆盖范围。

重大突破：自托管远程部署

关键是这样的。在你的本地机器上运行 MCP 对于开发和实验来说没问题。但在真实的团队场景中，你需要：

开发者和内部智能体系统的共享访问
集中化配置（租户上下文、订阅默认值、遥测）
企业网络和策略边界
与 CI/CD 流程的集成

Azure MCP Server 2.0 解决了所有这些问题。你可以将其部署为一个集中管理的内部服务，具有基于 HTTP 的传输、适当的身份验证和一致的治理。

对于身份验证，你有两个不错的选择：

托管标识——在 Microsoft Foundry 旁边运行时
代表流 (OBO 流)——OpenID Connect 委托，使用已登录用户的上下文调用 Azure API

对于我们 .NET 开发者来说，OBO 流特别有趣。这意味着你的智能工作流可以使用用户的实际权限运行，而不是某个过度特权的服务账户。最小权限原则，内置其中。

安全加固

这不仅仅是一个功能发布——它也是一个安全发布。2.0 版本添加了：

更强的端点验证
针对面向查询工具中注入模式的保护
更严格的开发环境隔离控制

如果你要将 MCP 暴露为共享服务，这些保障措施很重要。非常重要。

你可以在哪里使用它？

客户端兼容性范围很广。Azure MCP Server 2.0 可与以下配合使用：

IDE：VS Code、Visual Studio、IntelliJ、Eclipse、Cursor
CLI 智能体：GitHub Copilot CLI、Claude Code
独立版：用于简单设置的本地服务器
自托管远程：2.0 的新星

此外，还有针对 Azure 美国政府版和由 21Vianet 运营的 Azure 的主权云支持，这对于受管制的部署至关重要。

为什么这对 .NET 开发者很重要

如果你使用 .NET 构建智能应用——无论是使用 Semantic Kernel、Microsoft Agent Framework，还是你自己的编排——Azure MCP Server 2.0 让你能够以生产级的方式让你的智能体与 Azure 基础设施交互。没有自定义 REST 包装。没有服务特定的集成模式。只是 MCP。

结合几天前发布的 MCP 应用流畅 API，.NET MCP 生态系统正在快速成熟。

开始使用

选择你的路径：

GitHub 仓库——源代码、文档，一切
Docker 镜像——容器化部署
VS Code 扩展——IDE 集成
自托管指南——2.0 的旗舰功能

总结

Azure MCP Server 2.0 正是那种在演示中看起来不起眼但在实践中改变一切的基础设施升级。具有适当身份验证、安全加固和主权云支持的自托管远程 MCP 意味着 MCP 已为在 Azure 上构建真实智能工作流的真实团队做好准备。如果你一直在等待"企业就绪"的信号——就是现在。

.NET Aspire 13.2想成为你AI智能体的好朋友

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

你知道那种感觉吗？你的AI编码智能体写出了不错的代码，你很兴奋，然后当它试图运行这个东西时一切都崩溃了？端口冲突、幽灵进程、错误的环境变量 — 突然你的智能体在排查启动问题上烧掉了大量token，而不是构建功能。

Aspire团队刚刚发布了一篇关于这个问题的深思熟虑的文章，他们的答案很有说服力：Aspire 13.2的设计不仅面向人类，更面向AI智能体。

问题是真实存在的

AI智能体在写代码方面令人难以置信。但交付一个可工作的全栈应用涉及的远不止生成文件。你需要按正确的顺序启动服务、管理端口、设置环境变量、连接数据库，以及在出问题时获得反馈。目前，大多数智能体通过试错来处理所有这些 — 运行命令、读取错误输出、再试一次。

我们叠加Markdown指令、自定义技能和提示来引导它们，但这些是不可预测的，无法编译，而且仅仅解析就要消耗token。Aspire团队抓住了核心洞察：智能体需要编译器和结构化API，而不是更多的Markdown。

Aspire作为智能体基础设施

以下是Aspire 13.2为智能体开发带来的内容：

整个技术栈用类型化代码描述。 AppHost用可编译的TypeScript或C#定义你的完整拓扑 — API、前端、数据库、缓存：

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

智能体可以读取这些来理解应用拓扑、添加资源、连接组件，并通过构建来验证。编译器会立即告诉它哪里出了问题。不需要猜测，不需要在配置文件上反复试错。

一个命令统治所有。 智能体不再需要在docker compose up、npm run dev和数据库启动脚本之间来回切换，一切只需aspire start。所有资源按正确顺序、在正确的端口、用正确的配置启动。长时间运行的进程也不会挂起智能体 — Aspire负责管理它们。

并行智能体的隔离模式。 使用--isolated，每次Aspire运行都会获得自己的随机端口和独立的用户密钥。多个智能体在git worktree中工作？它们不会冲突。这对于VS Code的后台智能体等创建并行环境的工具来说意义重大。

通过遥测赋予智能体视野。 这是真正强大的地方。Aspire CLI在开发期间暴露完整的OpenTelemetry数据 — 追踪、指标、结构化日志。你的智能体不是只读控制台输出然后祈祷一切顺利。它可以跨服务追踪失败的请求、分析慢端点，并精确定位问题所在。这是开发循环中的生产级可观察性。

保龄球护栏类比

Aspire团队用了一个很棒的类比：把Aspire想象成AI智能体的保龄球道护栏。如果智能体不够完美（它确实不会完美），护栏会防止它打出沟球。技术栈定义防止配置错误，编译器捕获错误，CLI处理进程管理，遥测提供反馈循环。

将此与Playwright CLI之类的工具结合，你的智能体就可以真正使用你的应用 — 点击流程、检查DOM、在遥测中发现问题、修复代码、重启并重新测试。构建、运行、观察、修复。这就是我们一直追求的自主开发循环。

入门

Aspire新手？从get.aspire.dev安装CLI并遵循入门指南。

已经在使用Aspire？运行aspire update --self获取13.2，然后将你最喜欢的编码智能体指向你的仓库。有了Aspire的护栏，你可能会惊讶于它能走多远。

总结

Aspire 13.2不再仅仅是一个分布式应用框架 — 它正在成为必不可少的智能体基础设施。结构化的技术栈定义、一键启动、隔离的并行运行和实时遥测，为AI智能体提供了从编写代码到交付应用所需的一切。

阅读Aspire团队的完整文章获取所有细节和演示视频。

Aspire的隔离模式解决了并行开发中端口冲突的噩梦

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

如果你曾试过同时运行同一个项目的两个实例，你就知道那种痛苦。端口8080已被占用。端口17370已被使用。杀掉进程、重启、摆弄环境变量 — 这是生产力杀手。

这个问题在变得更严重，而不是更好。AI智能体创建git worktree来独立工作。后台智能体启动独立环境。开发者为了功能分支两次checkout同一个仓库。每一个场景都撞上了同一堵墙：同一个应用的两个实例在争夺相同的端口。

Aspire 13.2用一个flag就解决了这个问题。Aspire团队的James Newton-King写了完整的细节，这是那种"我们怎么之前没有这个"的功能。

解决方案：`--isolated`

aspire run --isolated

就这样。每次运行获得：

随机端口 — 实例间不再冲突
隔离的用户密钥 — 连接字符串和API密钥在每个实例间保持独立

不需要手动重新分配端口。不需要摆弄环境变量。每次运行自动获得一个干净的、无冲突的环境。

这个功能发光的真实场景

多次checkout。 你有一个功能分支在一个目录，一个bugfix在另一个：

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

两个都无冲突运行。仪表盘显示什么在运行以及在哪里运行。

VS Code中的后台智能体。 当Copilot Chat的后台智能体创建git worktree来独立处理你的代码时，它可能需要运行你的Aspire AppHost。没有--isolated，这就会和你的主worktree产生端口冲突。有了它，两个实例就能正常运行。

aspire agent init附带的Aspire技能会自动指导智能体在worktree中工作时使用--isolated。所以Copilot的后台智能体应该能原生处理这个问题。

开发同时运行集成测试。 需要在继续开发功能的同时对活跃的AppHost运行测试？隔离模式给每个上下文提供独立的端口和配置。

底层工作原理

当你传递--isolated时，CLI会为该运行生成一个唯一的实例ID。这驱动两个行为：

端口随机化 — 不再绑定到AppHost配置中定义的可预测端口，隔离模式为所有内容选择随机可用端口 — 仪表盘、服务端点，全部。服务发现自动调整，所以服务能找到彼此，不管它们落在哪个端口上。
密钥隔离 — 每个隔离运行获得自己的用户密钥存储，以实例ID为键。一次运行的连接字符串和API密钥不会泄露到另一次运行中。

你的代码不需要任何改动。Aspire的服务发现在运行时解析端点，所以不管端口分配如何，一切都能正确连接。

何时使用

当同时运行同一AppHost的多个实例时使用--isolated — 无论是并行开发、自动化测试、AI智能体还是git worktree。对于偏好可预测端口的单实例开发，常规的aspire run仍然可以正常使用。

总结

隔离模式是一个解决真实且越来越常见问题的小功能。随着AI辅助开发推动我们走向更多并行工作流 — 多个智能体、多个worktree、多个上下文 — 能够简单地启动另一个实例而不必争夺端口是必不可少的。

阅读完整文章获取所有技术细节，并用aspire update --self获取13.2来试用。

GitHub Copilot 的现代化评估是你还没用上的最好迁移工具

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

将传统 .NET Framework 应用迁移到现代 .NET 是那种每个人都知道应该做但没人想开始的任务。它从来不是简单的"更改目标框架"。而是消失的 API、不再存在的包、工作方式完全不同的托管模型，以及关于什么要容器化、什么要重写、什么要保持不变的无数小决策。

Jeffrey Fritz 刚刚发布了一篇 GitHub Copilot 现代化评估的深入解析，说实话？这是我见过的 .NET 最好的迁移工具。不是因为代码生成 — 那现在已经是标配了。而是因为它生成的评估文档。

它不仅仅是代码建议引擎

VS Code 扩展遵循评估 → 计划 → 执行模型。评估阶段分析你的整个代码库，生成一份结构化文档，捕获一切：什么需要更改、需要配置哪些 Azure 资源、使用什么部署模型。下游的一切 — 基础设施即代码、容器化、部署清单 — 都源自评估发现的内容。

评估存储在项目的 .github/modernize/assessment/ 下。每次运行产生一份独立的报告，因此你可以积累历史记录，并在修复问题时跟踪迁移态势的演变。

两种开始方式

推荐评估 — 快捷路径。从策划好的领域（Java/.NET 升级、云就绪、安全）中选择，无需配置即可获得有意义的结果。非常适合初次了解应用的状态。

自定义评估 — 定向路径。精确配置要分析的内容：目标计算（App Service、AKS、Container Apps）、目标操作系统、容器化分析。选择多个 Azure 目标来并排比较迁移方法。

那个比较视图真的很有用。一个应用在 App Service 上可能有 3 个必须解决的问题，在 AKS 上可能有 7 个。看到两者有助于在确定迁移路径之前做出托管决策。

问题分解是可操作的

每个问题都带有严重程度级别：

必须 — 必须修复，否则迁移失败
潜在 — 可能影响迁移，需要人工判断
可选 — 推荐的改进，不会阻止迁移

每个问题都链接到受影响的文件和行号，提供详细描述说明什么地方有问题以及为什么对目标平台重要，给出具体的修复步骤（不仅仅是"修复这个"），并包含官方文档链接。

你可以将单个问题分配给开发者，他们拥有行动所需的一切。这就是告诉你"有个问题"的工具和告诉你如何解决的工具之间的区别。

涵盖的升级路径

针对 .NET 具体来说：

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

每条升级路径都有检测规则，知道哪些 API 被移除、哪些模式没有直接等价物、哪些安全问题需要关注。

对于管理多个应用的团队，还有一个 CLI 支持多仓库批量评估 — 克隆所有仓库，全部评估，获取每个应用的报告加上汇总的组合视图。

我的看法

如果你坐拥传统 .NET Framework 应用（说实话，大多数企业团队都是这样），这就是那个应该开始使用的工具。仅评估文档就值得投入时间 — 它将模糊的"我们应该现代化"变成了一个具体的、有优先级的工作项列表，指明了前进的方向。

协作工作流也很聪明：导出评估、与团队分享、无需重新运行即可导入。决策者不是运行工具的人的架构评审？涵盖了。

总结

GitHub Copilot 的现代化评估将 .NET 迁移从一个可怕的、不明确的项目转变为一个结构化的、可跟踪的过程。从推荐评估开始了解你的现状，然后使用自定义评估来比较 Azure 目标并制定迁移计划。

阅读完整演练并获取 VS Code 扩展在你自己的代码库上试试。

MCP Apps 迎来 Fluent API — 三步在 .NET 中构建丰富的 AI 工具界面

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

MCP 工具非常适合赋予 AI 代理各种能力。但如果你的工具需要向用户展示某些东西呢？比如仪表板、表单或交互式可视化？这就是 MCP Apps 的用武之地，而且现在构建它们变得简单多了。

Azure SDK 团队的 Lilian Kasem 发布了全新的 Fluent 配置 API，用于 .NET Azure Functions 上的 MCP Apps。这种开发者体验的改进会让你想，为什么以前不一直这么简单呢。

什么是 MCP Apps？

MCP Apps 扩展了 Model Context Protocol，让工具可以携带自己的 UI 视图、静态资源和安全控制。你的 MCP 工具不再只是返回文本，而是可以渲染完整的 HTML 体验 — 交互式仪表板、数据可视化、配置表单 — 全部可由 AI 代理调用，并通过 MCP 客户端呈现给用户。

问题在于，手动连接这一切需要深入了解 MCP 规范：ui:// URI、特殊 MIME 类型、工具和资源之间的元数据协调。不难，但很繁琐。

Fluent API 三步走

第一步：定义你的函数。 标准的 Azure Functions MCP 工具：

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

第二步：将其提升为 MCP App。 在程序启动中：

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");
 }));

第三步：添加你的 HTML 视图。 创建 assets/hello-app.html，放入你需要的界面。

就这样。Fluent API 处理了所有 MCP 协议的管道工作 — 生成合成资源函数、设置正确的 MIME 类型、注入将工具与其视图连接起来的元数据。

API 设计精良

几个我特别喜欢的地方：

视图源灵活。 你可以从磁盘文件提供 HTML，也可以将资源直接嵌入程序集中以实现自包含部署：

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP 可组合。 你明确允许应用所需的来源，遵循最小权限原则。多次调用 WithCsp，来源会累积：

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

可见性控制。 你可以让工具仅对 LLM 可见、仅对宿主 UI 可见，或两者兼具。想要一个只渲染 UI 而不应被模型调用的工具？简单：

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

开始使用

添加预览包：

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

如果你已经在用 Azure Functions 构建 MCP 工具，这只是一个包更新。如果你是新手，MCP Apps 快速入门是最好的起点。

总结

MCP Apps 是 AI 工具领域最令人兴奋的发展之一 — 不仅能做事，还能向用户展示事物的工具。Fluent API 消除了协议复杂性，让你专注于真正重要的事：工具的逻辑和界面。

阅读完整文章获取完整的 API 参考和示例。

将 Azure Functions 上的 MCP 服务器连接到 Foundry 代理 — 方法在这里

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

这是我喜欢 MCP 生态系统的一点：你只需构建一次服务器，它就能在任何地方运行。VS Code、Visual Studio、Cursor、ChatGPT — 每个 MCP 客户端都能发现并使用你的工具。现在，微软正在向这个列表中添加另一个消费者：Foundry 代理。

Azure SDK 团队的 Lily Ma 发布了一份实用指南，介绍如何将部署在 Azure Functions 上的 MCP 服务器与 Microsoft Foundry 代理连接。如果你已经有了 MCP 服务器，这纯粹是增值 — 无需重新构建。

为什么这种组合有意义

Azure Functions 为托管 MCP 服务器提供了可扩展的基础设施、内置身份验证和无服务器计费。Microsoft Foundry 为你提供能够推理、规划和行动的 AI 代理。连接两者意味着你的自定义工具 — 查询数据库、调用业务 API、运行验证逻辑 — 成为企业 AI 代理可以自主发现和使用的能力。

关键点：你的 MCP 服务器保持不变。你只是将 Foundry 添加为另一个消费者。在 VS Code 设置中运行的相同工具现在为你的团队或客户交互的 AI 代理提供动力。

身份验证选项

这是文章真正增值的地方。根据你的场景提供四种身份验证方法：

方法	使用场景
基于密钥（默认）	开发或没有 Entra 身份验证的服务器
Microsoft Entra	使用托管标识的生产环境
OAuth 身份透传	每个用户单独认证的生产环境
无身份验证	开发/测试或仅公开数据

对于生产环境，使用代理身份的 Microsoft Entra 是推荐路径。OAuth 身份透传适用于用户上下文重要的场景 — 代理提示用户登录，每个请求携带用户自己的令牌。

设置方法

大致流程：

将 MCP 服务器部署到 Azure Functions — .NET、Python、TypeScript 和 Java 的示例均可用
在你的函数应用上启用内置 MCP 身份验证
获取你的端点 URL — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
在 Foundry 中添加 MCP 服务器作为工具 — 在门户中导航到你的代理，添加新的 MCP 工具，提供端点和凭据

然后在 Agent Builder 操场中发送一个会触发你某个工具的提示来测试它。

我的看法

这里的组合性故事变得非常强大。用 .NET（或 Python、TypeScript、Java）构建一次 MCP 服务器，部署到 Azure Functions，每个 MCP 兼容的客户端都能使用它 — 编码工具、聊天应用，现在还有企业 AI 代理。这是一个真正有效的"一次编写，到处使用"模式。

特别是对于 .NET 开发者，Azure Functions MCP 扩展让这一切变得简单明了。你将工具定义为 Azure Functions，部署，就拥有了一个具备 Azure Functions 所提供的所有安全性和可扩展性的生产级 MCP 服务器。

总结

如果你有在 Azure Functions 上运行的 MCP 工具，将它们连接到 Foundry 代理是一个快速的胜利 — 你的自定义工具变成了企业 AI 能力，具有适当的身份验证，且服务器本身无需代码更改。

阅读完整指南了解每种身份验证方法的分步说明，查看详细文档了解生产环境配置。

C# 15 引入联合类型 — 正是我们一直在期待的

Emiliano Montesdeoca — Sun, 05 Apr 2026 00:00:00 +0000

这就是我一直在等的那个功能。C# 15 引入了 union 关键字 — 真正的可区分联合类型，带有编译器强制的穷举模式匹配。如果你曾经羡慕过 F# 的可区分联合或 Rust 的 enum，你就明白这为什么重要了。

Bill Wagner 在 .NET 博客上发布了深度解析，说实话？设计干净、实用，非常 C#。让我带你看看实际有什么，以及为什么它比乍看之下更重要。

联合类型解决的问题

在 C# 15 之前，从方法返回"多个可能类型之一"总是一种妥协：

object — 没有约束，没有编译器帮助，到处都是防御性类型转换
标记接口 — 好一些，但任何人都可以实现它们。编译器永远无法认为集合是完整的
抽象基类 — 同样的问题，而且类型需要共同的祖先

这些都无法给你真正想要的东西：一个封闭的类型集合，编译器保证你已经处理了每种情况。这就是联合类型的作用。

语法优雅简洁

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

一行代码。Pet 可以包含一个 Cat、一个 Dog 或一个 Bird。隐式转换会自动生成：

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

魔法来了 — 编译器强制穷举匹配：

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

不需要丢弃模式 _。编译器知道这个 switch 覆盖了所有可能的情况。如果你之后向联合添加第四个类型，每个没有处理它的 switch 表达式都会产生警告。缺失的情况在编译时被捕获，而不是在运行时。

真正实用的地方

Pet 的例子很可爱，但这里才是联合类型在真实代码中真正发光的地方。

返回不同形状的 API 响应

public union ApiResult<T>(T, ApiError, ValidationFailure);

现在每个消费者都被强制处理成功、错误和验证失败。再也不会有"忘记检查错误情况"的 bug 了。

单值或集合

OneOrMore<T> 模式展示了联合如何拥有带有辅助方法的主体：

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

调用者传递最方便的形式：

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

组合不相关的类型

这是相对于传统继承层次结构的杀手级功能。你可以联合没有任何共同点的类型 — string 和 Exception、int 和 IEnumerable<T>。不需要共同祖先。

为现有库创建自定义联合

这是一个聪明的设计选择：任何带有 [Union] 属性的类或结构体都会被识别为联合类型，只要它遵循基本模式（case 类型的公共构造函数和 Value 属性）。像 OneOf 这样已经提供类似联合功能的库可以选择加入编译器支持，而无需重写其内部实现。

对于使用值类型的性能敏感场景，库可以通过 HasValue 和 TryGetValue 方法实现无装箱的访问模式。

更大的图景

联合类型是 C# 即将到来的更广泛穷举性故事的一部分：

联合类型 — 对封闭类型集合的穷举匹配（现已在预览版中可用）
密封层次结构 — closed 修饰符阻止在定义程序集之外派生类（已提议）
密封枚举 — 阻止创建声明成员之外的值（已提议）

这三个功能结合在一起，将使 C# 拥有所有主流语言中最全面的类型安全模式匹配系统之一。

今天就试试

联合类型在 .NET 11 Preview 2 中可用：

安装 .NET 11 Preview SDK
在项目中目标设为 net11.0
设置 <LangVersion>preview</LangVersion>

一个注意事项：在 Preview 2 中，你需要在项目中声明 UnionAttribute 和 IUnion，因为它们还没有包含在运行时中。从 docs 仓库获取 RuntimePolyfill.cs，或添加以下代码：

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

总结

联合类型是那种让你不禁感叹"以前没有它们我们是怎么过来的"的功能。编译器强制的穷举匹配、简洁的语法、泛型支持，以及与现有模式匹配的集成 — 这是我们一直要求的一切，以 C# 的方式实现。

在 .NET 11 Preview 2 中试用它们，尽情折腾，并在 GitHub 上分享你的反馈。这是预览版，C# 团队正在积极倾听。你的边界情况和设计反馈将塑造最终版本。

完整的语言参考请查看联合类型文档和功能规范。

Aspire 13.2 自带文档 CLI — 你的 AI 代理也能用

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

你知道那种时刻吗——你正深入一个 Aspire AppHost，接入各种集成，然后需要确认 Redis 集成到底需要哪些参数？你 Alt-Tab 切到浏览器，在 aspire.dev 上翻来翻去，眯着眼看 API 文档，然后切回编辑器。上下文没了，心流断了。

Aspire 13.2 刚刚发布了解决方案。aspire docs CLI 让你直接从终端搜索、浏览和阅读 Aspire 官方文档。而且因为它由可复用的服务支撑，AI 代理和技能可以使用同样的命令来查找文档，而不是幻想出不存在的 API。

这到底解决了什么问题

David Pine 在原文中说得很到位：AI 代理在帮助开发者构建 Aspire 应用方面糟糕透了。它们推荐 dotnet run 而不是 aspire run，引用 learn.microsoft.com 来查找实际在 aspire.dev 上的文档，建议过时的 NuGet 包，还有——我个人最喜欢的——幻想出根本不存在的 API。

为什么？因为 Aspire 作为 .NET 专属工具的时间远比它成为多语言工具的时间长，而且 LLM 使用的训练数据早于最新功能。当你给 AI 代理真正查找当前文档的能力时，它就不再猜测，开始变得有用了。

三个命令，零个浏览器标签页

CLI 简洁得令人耳目一新：

列出所有文档

aspire docs list

返回 aspire.dev 上所有可用的文档页面。需要机器可读的输出？加上 --format Json。

搜索主题

aspire docs search "redis"

同时搜索标题和内容，使用加权相关性评分。与内部驱动文档工具的搜索引擎完全一样。你会得到带有标题、slug 和相关性分数的排名结果。

阅读完整页面（或仅一个章节）

aspire docs get redis-integration

将完整页面以 markdown 格式流式传输到你的终端。只需要一个章节？

aspire docs get redis-integration --section "Add Redis resource"

精准定位。不用滚动 500 行。只看你需要的部分。

AI 代理的视角

对于我们这些使用 AI 工具进行开发的人来说，这才是真正有趣的地方。同样的 aspire docs 命令可以作为 AI 代理的工具——通过技能、MCP 服务器或简单的 CLI 封装。

你的 AI 助手不再根据过时的训练数据编造 Aspire API，而是可以调用 aspire docs search "postgres"，找到官方集成文档，阅读正确的页面，给你文档记录的方案。实时的、最新的文档——而不是模型六个月前记住的内容。

背后的架构是有意为之的。Aspire 团队构建了可复用的服务（IDocsIndexService、IDocsSearchService、IDocsFetcher、IDocsCache），而不是一次性集成。这意味着同一个搜索引擎为终端中的人类、编辑器中的 AI 代理以及 CI 流水线中的自动化服务。

真实场景

终端快速查询： 你已经深入到第三个文件，需要 Redis 配置参数。两个命令，九十秒，回去干活：

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI 辅助开发： 你的 VS Code 技能封装了 CLI 命令。你问"给我的 AppHost 添加一个 PostgreSQL 数据库"，代理在回答之前先查阅真实文档。没有幻觉。

CI/CD 验证： 你的流水线以编程方式根据官方文档验证 AppHost 配置。--format Json 输出可以干净地通过管道传递给 jq 和其他工具。

自定义知识库： 在构建自己的 AI 工具？将结构化 JSON 输出直接导入你的知识库：

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

不需要网页抓取。不需要 API 密钥。与文档工具内部使用的完全一样的结构化数据。

文档始终是最新的

这是我最欣赏的部分。CLI 不会下载快照——它通过基于 ETag 的缓存查询 aspire.dev。文档一旦更新，你的 CLI 和构建在其之上的所有技能都会反映出来。没有过时的副本，没有"但是 wiki 上说的是…“的尴尬时刻。

总结

aspire docs 是那种以简洁方式解决真实问题的小功能之一。人类获得了终端原生的文档访问。AI 代理获得了停止猜测、开始引用真实文档的方式。而且一切都由同一个事实来源支撑。

如果你正在使用 .NET Aspire 开发，还没试过这个 CLI，运行 aspire docs search "你的主题" 看看感觉如何。然后考虑将这些命令封装到你正在使用的任何 AI 技能或自动化设置中——你的代理会感谢你的。

查看 David Pine 的深入分析了解文档工具是如何构建的，以及官方 CLI 参考获取所有细节。

Microsoft Agent Framework 正式发布 1.0 — 这些才是 .NET 开发者真正需要关注的

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

如果你一直在关注 Agent Framework 从早期 Semantic Kernel 和 AutoGen 时代走来的历程，这次的消息意义重大。Microsoft Agent Framework 刚刚发布了 1.0 版本 — 生产就绪、API 稳定、长期支持承诺。它同时支持 .NET 和 Python，并且真正可以承载实际工作负载。

让我跳过公告的噪音，专注于你用 .NET 构建 AI 驱动应用时真正重要的内容。

简短版本

Agent Framework 1.0 将之前的 Semantic Kernel 和 AutoGen 统一为一个开源 SDK。一个代理抽象。一个编排引擎。多个 AI 提供商。如果你之前一直在 Semantic Kernel（企业模式）和 AutoGen（研究级多代理工作流）之间来回切换，现在可以停了。这就是那个唯一的 SDK。

入门简单得几乎不公平

这是一个在 .NET 中运行的代理：

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

就这些。几行代码，你就有了一个在 Azure Foundry 上运行的 AI 代理。Python 的等效代码同样简洁。随着需求增长，逐步添加函数工具、多轮对话和流式输出 — API 表面会平稳地扩展，不会变得奇怪。

多代理编排 — 这才是真正的核心

单个代理对演示来说够了，但生产场景通常需要协调。Agent Framework 1.0 附带了经过实战考验的编排模式，直接来自 Microsoft Research 和 AutoGen：

顺序执行 — 代理按顺序处理（写手 → 审核 → 编辑）
并发执行 — 并行分发给多个代理，汇聚结果
移交 — 一个代理根据意图委托给另一个代理
群组聊天 — 多个代理讨论并收敛到一个解决方案
Magentic-One — 来自 MSR 的研究级多代理模式

所有这些都支持流式处理、检查点、人机回路审批以及暂停/恢复。检查点部分至关重要 — 长时间运行的工作流在进程重启后依然可以恢复。对于我们这些用 Azure Functions 构建过持久工作流的 .NET 开发者来说，这感觉很熟悉。

最重要的功能

以下是我认为值得了解的要点：

中间件钩子。 你知道 ASP.NET Core 有中间件管道吗？同样的概念，但用于代理执行。拦截每个阶段 — 添加内容安全、日志记录、合规策略 — 而无需触碰代理的提示词。这就是让代理达到企业级标准的方式。

可插拔内存。 对话历史、持久键值状态、基于向量的检索。选择你的后端：Foundry Agent Service、Mem0、Redis、Neo4j，或者自己实现。内存是将无状态的 LLM 调用变成真正能记住上下文的代理的关键。

声明式 YAML 代理。 在版本控制的 YAML 文件中定义代理的指令、工具、内存和编排拓扑。通过单个 API 调用加载和运行。这对于想要在不重新部署代码的情况下迭代代理行为的团队来说是颠覆性的。

A2A 和 MCP 支持。 MCP（Model Context Protocol）让代理能够动态发现和调用外部工具。A2A（Agent-to-Agent 协议）实现跨运行时协作 — 你的 .NET 代理可以与其他框架中运行的代理进行协调。A2A 1.0 支持即将推出。

值得关注的预览功能

1.0 中有些功能以预览形式发布 — 功能可用但 API 可能会演进：

DevUI — 一个基于浏览器的本地调试器，用于实时可视化代理执行、消息流和工具调用。可以把它想象成 Application Insights，但用于代理推理。
GitHub Copilot SDK 和 Claude Code SDK — 直接从编排代码中使用 Copilot 或 Claude 作为代理工具。在同一工作流中将编程代理与其他代理组合在一起。
Agent Harness — 一个可定制的本地运行时，为代理提供对 shell、文件系统和消息循环的访问。可以理解为编码代理和自动化模式。
Skills — 可复用的领域能力包，为代理提供开箱即用的结构化能力。

从 Semantic Kernel 或 AutoGen 迁移

如果你有现有的 Semantic Kernel 或 AutoGen 代码，有专门的迁移助手可以分析你的代码并生成逐步迁移计划。Semantic Kernel 迁移指南和 AutoGen 迁移指南会引导你完成所有步骤。

如果你一直在使用 RC 包，升级到 1.0 只需更改版本号。

总结

Agent Framework 1.0 是企业团队一直在等待的生产里程碑。稳定的 API、多提供商支持、真正能在大规模下运行的编排模式，以及从 Semantic Kernel 和 AutoGen 的迁移路径。

该框架已在 GitHub 上完全开源，你今天就可以通过 dotnet add package Microsoft.Agents.AI 开始使用。查看快速入门指南和示例来动手实践。

如果你一直在等待"可以安全用于生产"的信号 — 就是现在。

Aspire 13.2的Dashboard现在有了遥测API — 这改变了一切

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

如果你一直在用 .NET Aspire 构建分布式应用，你已经知道dashboard是整个体验中最棒的部分。所有的trace、日志和指标都在一个地方 — 不需要外部的Jaeger，不需要Seq配置，不需要"让我看看另一个终端"的时刻。

Aspire 13.2 刚刚做了重大改进。James Newton-King 发布了更新公告，说实话，单是遥测导出和API功能就值得升级。

像正常人一样导出遥测数据

这是我们都经历过的场景：你在调试一个分布式问题，花了二十分钟终于复现了，现在你需要和团队分享发生了什么。之前？截图。复制粘贴trace ID。一如既往的混乱。

Aspire 13.2 添加了一个管理日志和遥测对话框，你可以：

清除所有遥测（在复现bug之前很有用）
将选定的遥测数据导出为标准OTLP/JSON格式的ZIP文件
稍后将该ZIP重新导入任何Aspire dashboard

最后一点是杀手级功能。你复现一个bug，导出遥测数据，附加到工作项，你的队友可以导入到自己的dashboard中，看到你所看到的完全一样的内容。不再需要"你能在你的机器上复现吗？"

单个trace、span和日志也在上下文菜单中有了"Export JSON"选项。需要分享一个特定的trace？右键点击，复制JSON，粘贴到PR描述中。搞定。

遥测API才是真正的革命性变化

这是最让我兴奋的。Dashboard现在在/api/telemetry下暴露了HTTP API，用于编程式查询遥测数据。可用端点：

GET /api/telemetry/resources — 列出有遥测数据的资源
GET /api/telemetry/spans — 带过滤器查询span
GET /api/telemetry/logs — 带过滤器查询日志
GET /api/telemetry/traces — 列出trace
GET /api/telemetry/traces/{traceId} — 获取特定trace的所有span

一切都以OTLP JSON格式返回。这驱动了新的CLI命令aspire agent mcp和aspire otel，但真正的意义更大：你现在可以构建工具、脚本和AI代理集成，直接查询你应用的遥测数据。

想象一个AI编码代理在调试时能看到你实际的分布式trace。这不再是假设 — 这就是这个API所实现的。

GenAI遥测变得实用

如果你正在用Semantic Kernel或Microsoft.Extensions.AI构建AI驱动的应用，你会喜欢改进的GenAI遥测可视化器。Aspire 13.2 新增了：

AI工具描述以Markdown渲染
Trace页面上的专用GenAI按钮，方便快速访问
对截断或非标准GenAI JSON更好的错误处理
工具定义之间的点击高亮导航

文章提到VS Code Copilot chat、Copilot CLI和OpenCode都支持配置OTEL_EXPORTER_OTLP_ENDPOINT。将它们指向Aspire dashboard，你可以通过遥测数据实时观看你的AI代理思考过程。这是你在其他任何地方都找不到的调试体验。

总结

Aspire 13.2将dashboard从"不错的调试UI"转变为"可编程的可观测性平台"。单是导出/导入工作流就能在分布式调试中节省真实时间，而遥测API为AI辅助诊断打开了大门。

如果你已经在用Aspire，升级吧。如果还没有 — 这是一个了解aspire.dev的好理由。

azd现在可以在本地运行和调试AI代理了 — 2026年3月都有哪些变化

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

一个月七个版本。这是Azure Developer CLI (azd) 团队在2026年3月发布的成果，而头条功能正是我一直在等的：AI代理的本地运行和调试循环。

PC Chan 发布了完整摘要，虽然内容很多，但让我筛选出对构建AI驱动应用的.NET开发者真正重要的部分。

不用部署就能运行和调试AI代理

这是最大的亮点。新的 azure.ai.agents 扩展添加了一组命令，为AI代理提供了完整的内循环体验：

azd ai agent run — 在本地启动你的代理
azd ai agent invoke — 向其发送消息（本地或已部署的）
azd ai agent show — 显示容器状态和健康状况
azd ai agent monitor — 实时流式传输容器日志

以前，测试AI代理意味着每次修改都要部署到Microsoft Foundry。现在你可以在本地迭代，测试代理行为，准备好了再部署。

GitHub Copilot为你配置azd项目

azd init 现在提供了"Set up with GitHub Copilot (Preview)“选项。无需手动回答关于项目结构的提示，Copilot代理为你生成配置。当命令失败时，azd 提供AI辅助的问题排查——全程不需要离开终端。

Container App Jobs和部署改进

Container App Jobs：azd现在通过现有的host: containerapp配置部署Microsoft.App/jobs。
可配置的部署超时：azd deploy的新--timeout标志和azure.yaml中的deployTimeout字段。
远程构建回退：当ACR构建失败时，azd自动回退到本地Docker/Podman构建。
本地预检验证：部署前在本地验证Bicep参数。

开发体验改进

自动检测pnpm/yarn — JS/TS项目
pyproject.toml支持 — Python打包
本地模板目录 — azd init --template接受文件系统路径
更好的错误消息 — --no-prompt模式
构建环境变量 — 注入到所有框架构建子进程（.NET、Node.js、Java、Python）

总结

本地AI代理调试循环是这个版本的明星，但部署改进和DX优化的积累使azd比以往更加成熟。如果你在Azure上部署.NET应用——特别是AI代理——这次更新值得关注。

查看完整发行说明了解所有细节。

Visual Studio 3月更新允许构建自定义Copilot代理 — find_symbol是一大亮点

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

Visual Studio刚刚获得了最重要的Copilot更新。Mark Downie 发布了3月版本，标题是自定义代理——但说实话，find_symbol工具可能才是最能改变你工作流的功能。

仓库中的自定义Copilot代理

想让Copilot遵循你团队的编码标准？自定义代理定义为.github/agents/中的.agent.md文件。每个代理都有完整的工作区感知、代码理解、工具、首选模型和MCP连接访问权限。

代理技能：可复用的指令包

技能从仓库的.github/skills/或个人资料的~/.copilot/skills/自动加载。

find_symbol：语言感知导航

新的find_symbol工具为Copilot的代理模式提供了基于语言服务的符号导航。代理不再搜索文本，而是可以找到符号的所有引用并访问类型信息和作用域。

对于.NET开发者来说这是巨大改进——拥有深层类型层次结构的C#代码库受益匪浅。

用Copilot分析测试性能

Test Explorer上下文菜单中新增了Profile with Copilot。Profiling Agent自动运行测试并分析性能。

实时调试中的Perf Tips

性能优化现在在调试过程中进行。Visual Studio内联显示执行时间。看到慢的行？点击Perf Tip向Copilot请求优化建议。

从Solution Explorer修复NuGet漏洞

当检测到NuGet包漏洞时，Solution Explorer中直接显示Fix with GitHub Copilot链接。

总结

自定义代理和技能是标题，但find_symbol是隐藏的亮点——它从根本上改变了Copilot重构.NET代码时的准确性。下载Visual Studio 2026 Insiders来体验所有新功能。

KubeCon Europe 2026：.NET 开发者真正需要关注的内容

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

本文为自动翻译。查看原文请点击这里。

你知道那种感觉吗？一个巨大的公告文章出来了，你一边滚动一边想"不错，但这对我到底有什么改变"？这就是我每个 KubeCon 季的状态。

微软刚刚发布了他们的 KubeCon Europe 2026 完整总结——出自 Brendan Burns 本人之手——说实话？这次有真正的干货。不只是功能清单，而是真正改变你在生产环境中运维方式的运营改进。

让我来梳理一下对我们 .NET 开发者真正重要的内容。

不用付服务网格税的 mTLS

服务网格的问题在于：每个人都想要安全保障，没人想要运营负担。AKS 终于在弥补这个差距了。

Azure Kubernetes Application Network 给你提供了双向 TLS、应用感知授权和流量遥测——不需要部署一个带 sidecar 的重型 mesh。结合 Advanced Container Networking Services 中的 Cilium mTLS，你可以获得使用 X.509 证书和 SPIRE 身份管理的加密 pod 间通信。

这在实践中意味着什么：你的 ASP.NET Core API 与后台 worker 通信，你的 gRPC 服务互相调用——全部在网络层加密和身份验证，零应用代码更改。这意义重大。

对于从 ingress-nginx 迁移的团队，还有 Meshless Istio 的 Application Routing 全面支持 Kubernetes Gateway API。无 sidecar。基于标准。并且发布了 ingress2gateway 工具用于增量迁移。

不再是事后想到的 GPU 可观测性

如果你在 .NET 服务旁运行 AI 推理（说实话，谁现在还没开始？），你可能遇到过 GPU 监控盲区。CPU/内存仪表板很棒，然后 GPU 部分…没有手动配置导出器就什么都没有。

AKS 现在原生暴露 GPU 指标到托管的 Prometheus 和 Grafana。同样的技术栈，同样的仪表板，同样的告警管道。无需自定义导出器，无需第三方代理。

在网络方面，增加了 HTTP、gRPC 和 Kafka 流量的逐流可见性，配合一键 Azure Monitor 体验。IP、端口、工作负载、流方向、策略决策——全部在内置仪表板中。

让我看了两遍的是：agentic container networking 添加了一个 Web UI，你可以用自然语言询问集群的网络状态。“为什么 pod X 无法到达服务 Y？"→ 从实时遥测获取只读诊断。凌晨两点真的很有用。

不需要博士学位的跨集群网络

多集群 Kubernetes 历来是"自带网络胶水"的体验。Azure Kubernetes Fleet Manager 现在通过托管 Cilium 集群网格提供跨集群网络：

AKS 集群间的统一连接
用于跨集群发现的全局服务注册表
集中管理配置，而不是每个集群重复

如果你为了弹性或合规在多个区域运行 .NET 微服务，这替代了很多脆弱的自定义胶水。West Europe 的服务 A 可以通过网格发现和调用 East US 的服务 B，使用一致的路由和安全策略。

不需要勇气的升级

说实话——生产环境中的 Kubernetes 升级是有压力的。“升级然后祈祷"一直是太多团队的实际策略，也是集群版本落后的主要原因。

两个新功能改变了这一点：

Blue-green 代理池升级 用新配置创建一个并行节点池。验证行为，逐步转移流量，保持干净的回滚路径。不再在生产节点上进行就地变更。

代理池回滚 允许你在升级出问题后将节点池恢复到之前的 Kubernetes 版本和节点镜像——无需重建集群。

两者结合，终于给运维人员提供了对升级生命周期的真正控制。对于 .NET 团队来说很重要，因为平台速度直接控制你能多快采用新的运行时、安全补丁和网络能力。

AI 工作负载成为 Kubernetes 一等公民

上游开源工作同样重要。Dynamic Resource Allocation (DRA) 刚在 Kubernetes 1.36 中 GA，使 GPU 调度成为真正的一等功能而不是变通方案。

值得关注的项目：

项目	作用
AI Runway	推理的通用 Kubernetes API——不懂 K8s 也能部署模型，带 HuggingFace 发现和成本估算
HolmesGPT	云原生的智能体故障排除——现在是 CNCF Sandbox 项目
Dalec	带 SBOM 生成的声明式容器镜像构建——构建阶段减少 CVE

方向很明确：你的 .NET API、Semantic Kernel 编排层和推理工作负载应该都运行在一个一致的平台模型上。我们正在接近。

这周我会从哪里开始

如果你在为团队评估这些变化，这是我真诚的优先级列表：

先搞可观测性——在非生产集群中启用 GPU 指标和网络流日志。看看你一直错过了什么。
测试 blue-green 升级——在下次生产集群升级前测试回滚工作流。建立对流程的信心。
试点身份感知网络——选择一个内部服务路径并用 Cilium 启用 mTLS。测量开销（剧透：很小）。
评估 Fleet Manager——如果你运行超过两个集群，跨集群网络光减少自定义胶水就能回本。

小实验，快反馈。这永远是正确的做法。

总结

KubeCon 公告可能让人应接不暇，但这批更新确实为 AKS 上的 .NET 团队带来了实质性改变。更好的网络安全（无 mesh 开销）、真正的 GPU 可观测性、更安全的升级以及更强大的 AI 基础设施支撑。

如果你已经在用 AKS，现在是加强运营基准的好时机。如果你计划将 .NET 工作负载迁移到 Kubernetes——平台刚刚变得更加适合生产环境了。

Foundry Agent Service 正式发布：对 .NET 代理开发者真正重要的是什么

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

说实话 — 构建一个 AI 代理原型是简单的部分。困难的是之后的一切：用适当的网络隔离投入生产、运行真正有意义的评估、处理合规要求，以及不在凌晨 2 点搞崩东西。

Foundry Agent Service 刚刚正式发布，这个版本像激光一样聚焦在"之后一切"的鸿沟上。

构建在 Responses API 之上

标题新闻：新一代 Foundry Agent Service 构建在 OpenAI Responses API 之上。如果你已经在用这个 wire protocol 构建，迁移到 Foundry 只需最少的代码改动。你获得的：企业安全、私有网络、Entra RBAC、完整追踪和评估 — 在你现有的代理逻辑之上。

架构是有意开放的。你不被锁定在一个模型提供商或一个编排框架上。用 DeepSeek 做规划、OpenAI 做生成、LangGraph 做编排 — 运行时处理一致性层。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

私有网络：企业阻碍已移除

这是解锁企业采用的功能。Foundry 现在支持完整的端到端私有网络配合 BYO VNet：

无公共出口 — 代理流量永远不会触及公共互联网
容器/子网注入到你的网络以实现本地通信
工具连接也包含在内 — MCP 服务器、Azure AI Search、Fabric 数据代理都通过私有路径运作

最后一点至关重要。不只是推理调用保持私有 — 每个工具调用和检索调用也都留在你的网络边界内。对于在数据分类策略下禁止外部路由的团队来说，这就是缺失的那块。

MCP 认证做对了

MCP 服务器连接现在支持完整的认证模式谱系：

认证方式	何时使用
基于密钥	组织范围内部工具的简单共享访问
Entra Agent Identity	服务间；代理以自身身份认证
Entra Managed Identity	按项目隔离；无凭证管理
OAuth Identity Passthrough	用户委托访问；代理代表用户行事

OAuth Identity Passthrough 是有趣的那个。当用户需要授予代理访问他们的个人数据 — 他们的 OneDrive、Salesforce 组织、按用户范围的 SaaS API — 代理使用标准 OAuth 流程代表他们行事。没有假装是所有人的共享系统身份。

Voice Live：无需管道工程的语音对语音

给代理添加语音曾经意味着拼凑 STT、LLM 和 TTS — 三个服务、三次延迟跳转、三个计费面，全部手动同步。Voice Live 将这一切压缩为单个托管 API：

语义语音活动和轮次结束检测（理解含义，不仅仅是沉默）
服务端噪声抑制和回声消除
插话支持（用户可以在响应中途打断）

语音交互通过与文本相同的代理运行时。相同的评估器、相同的追踪、相同的成本可见性。对于客户支持、现场服务或无障碍场景，这取代了以前需要自定义音频管道的方案。

评估：从勾选框到持续监控

这是 Foundry 认真对待生产质量的地方。评估系统现在有三层：

开箱即用评估器 — 连贯性、相关性、扎实度、检索质量、安全性。连接到数据集或实时流量获取分数。
自定义评估器 — 编码你自己的业务逻辑、语调标准和领域特定合规规则。
持续评估 — Foundry 采样实时生产流量，运行你的评估器套件，并在仪表板中显示结果。设置 Azure Monitor 告警以监控扎实度下降或安全阈值突破。

一切发布到 Azure Monitor Application Insights。代理质量、基础设施健康、成本和应用遥测 — 全在一处。

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

六个新区域支持托管代理

托管代理现在在 East US、North Central US、Sweden Central、Southeast Asia、Japan East 等区域可用。这对数据驻留要求很重要，也有助于在代理靠近数据源运行时压缩延迟。

为什么这对 .NET 开发者重要

虽然 GA 公告中的代码示例是 Python 优先的，但底层基础设施是语言无关的 — azure-ai-projects 的 .NET SDK 遵循相同的模式。Responses API、评估框架、私有网络、MCP 认证 — 这些都可以从 .NET 使用。

如果你一直在等 AI 代理从"酷炫演示"变成"我真的可以在工作中交付"，这个 GA 版本就是信号。私有网络、适当的认证、持续评估和生产监控是缺失的那些拼图。

总结

Foundry Agent Service 现在可用。安装 SDK，打开门户，开始构建。快速入门指南带你在几分钟内从零到运行中的代理。

包含所有代码示例的完整技术深度分析，请查看 GA 公告。

Microsoft Agent Framework 中的后台响应：告别超时焦虑

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

如果你用 o3 或 GPT-5.2 等推理模型构建过任何东西，你就知道那种痛苦。你的代理开始思考一个复杂的任务，客户端在那里等待，在"没问题"和"它是不是崩了？“之间的某个时刻，你的连接超时了。那些工作？全没了。

Microsoft Agent Framework 刚刚推出了后台响应 — 说实话，这是那种从第一天就应该存在的功能。

阻塞调用的问题

在传统的请求-响应模式中，你的客户端会阻塞直到代理完成。对于快速任务来说没问题。但当你让推理模型做深度研究、多步分析或生成 20 页报告时？你面对的是几分钟的实际等待时间。在这个窗口期：

HTTP 连接可能超时
网络抖动会杀死整个操作
你的用户盯着一个加载动画想知道是否有事情在发生

后台响应彻底翻转了这个局面。

延续令牌如何工作

你不再阻塞等待，而是启动代理任务并获得一个延续令牌。把它想象成修理店的取件单 — 你不需要站在柜台前等着，准备好了再回来取就行。

流程很简单：

使用 AllowBackgroundResponses = true 发送请求
如果代理支持后台处理，你会收到一个延续令牌
按你的节奏轮询，直到令牌返回 null — 这意味着结果准备好了

这是 .NET 版本：

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// 轮询直到完成
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

如果代理立即完成（简单任务、不需要后台处理的模型），不会返回延续令牌。你的代码正常工作 — 无需特殊处理。

带恢复的流式传输：真正的魔法

轮询对于即发即忘的场景没问题，但当你想要实时进度呢？后台响应也支持带内置恢复功能的流式传输。

每个流式更新都携带自己的延续令牌。如果你的连接在流传输中断了，你可以从中断的确切位置恢复：

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // 模拟网络中断
}

// 从中断的确切位置恢复
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

无论客户端发生什么，代理都会继续在服务器端处理。这是内置的容错能力，无需你编写重试逻辑或断路器。

什么时候该真正使用这个

不是每个代理调用都需要后台响应。对于快速完成，你只是在无故增加复杂性。但以下场景是它们大放异彩的地方：

复杂推理任务 — 多步分析、深度研究、任何让推理模型真正思考的内容
长内容生成 — 详细报告、多部分文档、广泛分析
不可靠的网络 — 移动客户端、边缘部署、不稳定的企业 VPN
异步 UX 模式 — 提交任务，去做别的事，回来取结果

对于构建企业应用的 .NET 开发者来说，最后一点特别有趣。想想一个 Blazor 应用，用户请求一个复杂的报告 — 你启动代理任务，显示进度指示器，让他们继续工作。不需要 WebSocket 体操，不需要自定义队列基础设施，只需一个令牌和一个轮询循环。

总结

后台响应现在通过 Microsoft Agent Framework 在 .NET 和 Python 中都可用。如果你构建的代理做的事情比简单的问答更复杂，这值得加入你的工具包。延续令牌模式保持简单的同时解决了一个非常真实的生产问题。

查看完整文档获取完整的 API 参考和更多示例。

VS Code 1.112：.NET 开发者真正应该关注的内容

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

VS Code 1.112 刚落地，说实话？如果你每天都在 .NET 的世界里，这个版本感觉不一样。官方发布说明里有很多内容，但让我帮你省点滚动，专注于对我们真正重要的东西。

Copilot CLI 变得更有用了

这个版本的大主题是代理自主性 — 给 Copilot 更多空间做它的事，不需要你看管每一步。

消息引导和排队

你知道 Copilot CLI 在任务进行到一半时，你突然想起忘了提什么东西的那个时刻吗？以前你只能等。现在你可以在请求还在运行时发送消息 — 要么引导当前响应，要么排队后续指令。

这对那些较长的 dotnet 脚手架任务来说太棒了，你看着 Copilot 设置项目然后想"哦等等，我还需要 MassTransit"。

权限级别

这是我最兴奋的。Copilot CLI 会话现在支持三个权限级别：

默认权限 — 工具在运行前请求确认的常规流程
跳过审批 — 自动批准一切并在出错时重试
自动驾驶 — 完全自主：批准工具、回答自己的问题、持续到任务完成

如果你在做类似用 Entity Framework、migrations 和 Docker 设置创建新的 ASP.NET Core API 这样的事 — 自动驾驶模式意味着你描述想要什么然后去拿杯咖啡。它会搞定的。

你可以用 chat.autopilot.enabled 设置启用自动驾驶。

委托前预览更改

当你把任务委托给 Copilot CLI 时，它会创建一个 worktree。以前如果你有未提交的更改，你得检查源代码管理来看什么会受影响。现在聊天视图会在你决定复制、移动或忽略之前直接显示待处理的更改。

小事情，但省去了"等等，我 staging 了什么？“的时刻。

不离开 VS Code 就能调试 Web 应用

集成浏览器现在支持完整调试。你可以设断点、单步执行代码、检查变量 — 全在 VS Code 内。不用再切换到 Edge DevTools 了。

有一个新的 editor-browser 调试类型，如果你已经有 msedge 或 chrome 的启动配置，迁移只需改 launch.json 里的 type 字段：

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

对 Blazor 开发者来说，这是颠覆性的。你已经在终端运行 dotnet watch — 现在调试也留在同一个窗口里。

浏览器还获得了独立的缩放级别（终于）、正确的右键上下文菜单，缩放按网站记忆。

MCP 服务器沙箱

这比你想的更重要。如果你在用 MCP 服务器 — 也许你为 Azure 资源或数据库查询设置了自定义的 — 它们一直以和你的 VS Code 进程相同的权限运行。这意味着对你的文件系统、网络等一切的完全访问。

现在你可以对它们做沙箱处理。在你的 mcp.json 中：

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

当沙箱化的服务器需要访问它没有的东西时，VS Code 会提示你授予权限。比"希望没人做奇怪的事"的方式好太多了。

Monorepo 自定义发现

如果你在 monorepo 中工作（说实话，很多企业 .NET 解决方案最终都变成了 monorepo），这解决了一个真正的痛点。

以前，如果你打开仓库的子文件夹，VS Code 找不到仓库根目录的 copilot-instructions.md、AGENTS.md 或自定义技能。现在通过 chat.useCustomizationsInParentRepositories 设置，它会向上查找到 .git 根目录并发现所有内容。

这意味着你的团队可以在 monorepo 中跨所有项目共享代理指令、提示文件和自定义工具，不需要每个人都打开根文件夹。

/troubleshoot 用于代理调试

有没有设置过自定义指令或技能，然后纳闷为什么没被检测到？新的 /troubleshoot 技能读取代理调试日志并告诉你发生了什么 — 哪些工具被使用或跳过了，为什么指令没加载，什么导致了慢响应。

用以下配置启用：

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

然后在聊天中输入 /troubleshoot why is my custom skill not loading?。

你现在还可以导出和导入这些调试日志，当某些东西不按预期工作时，和团队分享很方便。

图像和二进制文件支持

代理现在可以从磁盘原生读取图像文件和二进制文件。二进制文件以 hexdump 格式呈现，图像输出（如集成浏览器的截图）以轮播视图显示。

对 .NET 开发者来说：把 UI bug 的截图粘贴到聊天中让代理理解问题所在，或者让它分析 Blazor 组件渲染的输出。

自动符号引用

小的生活质量改善：当你复制一个符号名称（类、方法等）并粘贴到聊天中时，VS Code 现在自动将其转换为 #sym:Name 引用。这给代理提供了关于该符号的完整上下文，无需手动添加。

如果你想要纯文本，使用 Ctrl+Shift+V。

插件现在可以启用/禁用

以前禁用 MCP 服务器或插件意味着卸载它。现在你可以开关它们 — 全局和按工作区都可以。在扩展视图或自定义视图中右键单击就行。

npm 和 pypi 的插件现在也可以自动更新了，不过会先请求批准，因为更新意味着在你的机器上运行新代码。

总结

VS Code 1.112 明显在大力推进代理体验 — 更多自主性、更好的调试、更严格的安全。对 .NET 开发者来说，集成浏览器调试和 Copilot CLI 改进是最突出的功能。

如果你还没试过为 .NET 项目在自动驾驶模式下运行完整的 Copilot CLI 会话，这个版本是开始的好时机。记得设置你的权限然后让它干活。

下载 VS Code 1.112 或在 VS Code 内通过帮助 > 检查更新进行更新。

Dotnet | The .NET Blog

SDD Conference 2026

主题

演讲者

门票和信息

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

什么是钩子

检测机制

各语言的重要细节

Python

JavaScript和TypeScript

.NET

执行器特定配置

对.NET开发者的意义

总结

Windows App Dev CLI v0.3：从终端实现F5调试和面向智能体的UI自动化

winapp run：随处可用的F5

新NuGet包：打包应用的dotnet run支持

winapp ui：从命令行实现UI自动化

其他新功能

安装方式

别再盯着终端了：Aspire 的分离模式改变了工作流程

分离模式：一条命令，终端回来了

管理正在运行的进程

与隔离模式结合使用

为什么这对编码代理意义重大

总结

Pin 聚类终于登陆 .NET MAUI Maps — 一个属性，零痛苦

一个属性统治一切

独立的聚类分组

处理聚类点击

值得了解的平台细节

为什么这很重要

开始使用

.NET 2026年4月服务更新 — 你今天就该应用的安全补丁

修补内容

更新版本

应该怎么做

Azure MCP Server 2.0 正式发布——自托管智能云自动化来了

什么是 Azure MCP Server？

重大突破：自托管远程部署

安全加固

你可以在哪里使用它？

为什么这对 .NET 开发者很重要

开始使用

总结

.NET Aspire 13.2想成为你AI智能体的好朋友

问题是真实存在的

Aspire作为智能体基础设施

保龄球护栏类比

入门

总结

Aspire的隔离模式解决了并行开发中端口冲突的噩梦

解决方案：--isolated

这个功能发光的真实场景

底层工作原理

何时使用

总结

GitHub Copilot 的现代化评估是你还没用上的最好迁移工具

它不仅仅是代码建议引擎

两种开始方式

问题分解是可操作的

涵盖的升级路径

我的看法

总结

MCP Apps 迎来 Fluent API — 三步在 .NET 中构建丰富的 AI 工具界面

什么是 MCP Apps？

Fluent API 三步走

API 设计精良

开始使用

总结

将 Azure Functions 上的 MCP 服务器连接到 Foundry 代理 — 方法在这里

为什么这种组合有意义

身份验证选项

设置方法

我的看法

总结

C# 15 引入联合类型 — 正是我们一直在期待的

联合类型解决的问题

语法优雅简洁

解决方案：`--isolated`