Cli | The .NET Blog

dotnet new WinUI：无需 Visual Studio 即可创建 Windows 应用

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

WinUI 开发过去需要 Visual Studio。这一情况正在改变：Microsoft 发布了适用于 WinUI 的开源项目和项目模板，这些模板可与 dotnet new 配合使用，将 Windows 应用开发纳入标准 CLI 工作流。

三条命令即可开始

# 安装模板
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates

# 创建 NavigationView 应用
dotnet new winui-navview -n MyApp

# 运行
cd MyApp
dotnet run

无需 Visual Studio，无需手动配置项目。应用通过 dotnet run 运行。

包含的内容

空白模板（dotnet new winui）——现代化的起点，已连接 Fluent 标题栏，包含带 .ico 资源的更新默认应用图标，以及正确的浅色/深色模式默认值。比旧版空白模板更好，后者需要你自己配置基础设置。

NavigationView 模板（dotnet new winui-navview）——主从导航模式，完整连接了 NavigationView、现代标题栏和多页导航结构。遵循基于导航的应用的标准 Windows 应用轮廓。如果你要构建带侧边导航的应用，请从这里开始。

两个模板都开箱即遵循 Windows 应用轮廓——用于布局、导航和视觉结构的现代 Fluent Design 模式。

为什么对非 Visual Studio 开发者很重要

使用 VS Code、Rider 或命令行工具的 WinUI 开发者一直处于不利地位。现有的 Visual Studio 模板无法在 VS 之外使用——必须手动重建项目结构并配置基础内容。

这些模板是开源的（参见 WindowsAppSDK PR #6407），基于社区反馈开发，现已可用。Visual Studio 支持正在开发中——这些相同的模板最终也将在那里运行。

对于希望自动化 WinUI 项目设置、将其集成到 CI 中，或者只是想使用 Visual Studio 以外的编辑器的团队来说，这是一个有意义的改进。

原文：Introducing dotnet new WinUI templates

Cosmos DB Shell 现已推出公共预览版 — 并且内置了 MCP 服务器

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

如果您曾经为了回答一个关于 Cosmos DB 的问题，不得不在门户标签页、SDK 示例和半成品脚本之间来回切换，那么您已经了解这个项目旨在消除的摩擦。

Azure Cosmos DB Shell 刚刚进入公共预览版。这是一个具有类 bash 语法的开源 CLI，还有——让它变得有趣的部分——一个内置的 MCP 服务器。

与其他数据库 CLI 的不同之处

CLI 本身很有用：熟悉的命令、脚本支持、CI/CD 集成。这部分是面向开发者的数据库工具的最低要求。

有趣的部分是 MCP 服务器集成。CLI 公开的每个命令都可以作为 AI 代理可以调用的 MCP 工具。没有自定义 API 层，没有需要编写的集成代码。您的代理可以：

使用 cd、ls、pwd 导航数据库层次结构
使用 query 执行 SQL 查询并获取结构化结果
使用 create item、update、rm 创建和修改项目
使用 mkdb、mkcon、rmdb、rmcon 管理数据库和容器
使用 endpoint、pwd 检查当前上下文

关键变化：您的代理不是在与 Cosmos DB API 交互——而是在与您使用的相同 shell 界面交互。命令是确定性的、可审计的，并且是开源的，因此您可以检查确切发生了什么。

开源基础很重要

这不是一个黑箱托管服务。Shell 是开源的，这意味着：

安全团队可以审计实现
平台团队可以 fork 并根据其特定标准进行扩展
开发者可以贡献对所有人有益的改进

对于采用 AI 工具的企业团队来说，“我们能确切看到它是如何工作的吗"越来越不是可选要求。这里的开源是一个重要的差异化因素。

三个变得更容易的场景

智能数据分析 — 将代理连接到 shell，用自然语言提问，获取结构化查询结果。代理处理查询构建；shell 处理执行。

自主数据管理 — 需要在 Cosmos DB 中创建、更新或删除数据的工作流可以通过 MCP 工具完成，无需自定义集成。

实时监控和警报 — 代理可以定期查询容器，比较结果，并通过任何有意义的通知渠道报告异常。

MCP 接口使这些场景可以与任何支持 MCP 的 AI 平台组合——不仅仅是微软的工具。

入门

Shell 处于公共预览阶段。安装它，配置您的 Cosmos DB 连接，并启用 MCP 服务器。从那里，任何 MCP 兼容的代理宿主都可以发现并使用这些工具。

原始文章：Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

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。

azd update — 一个命令搞定所有包管理器

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

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

你知道那个每隔几周就会弹出来的"azd 有新版本可用"提示吗？就是那个你总是忽略掉的，因为你根本想不起来当初是用 winget、Homebrew 还是半年前跑的那个 curl 脚本安装的 azd。好了，这个问题终于解决了。

Microsoft 刚刚发布了 azd update — 一个命令就能将 Azure Developer CLI 更新到最新版本，不管你最初是怎么安装的。Windows、macOS、Linux — 都一样。就一个命令。

工作原理

azd update

就这么简单。如果你想提前体验新功能，可以切换到每日 Insiders 构建：

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

这个命令会自动检测你当前的安装方式，并在后台使用对应的更新机制。再也不用纠结"等等，这台机器上我用的是 winget 还是 choco 来着？"

一个小前提

azd update 从版本 1.23.x 开始提供。如果你用的是更早的版本，需要用原来的安装方式做最后一次手动更新。之后，azd update 就能接管一切了。

用 azd version 查看你当前的版本。如果需要全新安装，安装文档可以帮到你。

为什么这很重要

这是一个小小的生活质量改善，但对于我们这些每天都在用 azd 把 AI Agent 和 Aspire 应用部署到 Azure 的人来说，保持最新意味着更少的"这个 bug 在最新版本里已经修复了"的尴尬时刻。少操心一件事。

阅读完整公告和 Jon Gallant 的深入分析了解更多。

.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来试用。

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 参考获取所有细节。

Cli | The .NET Blog

dotnet new WinUI：无需 Visual Studio 即可创建 Windows 应用

三条命令即可开始

包含的内容

为什么对非 Visual Studio 开发者很重要

Cosmos DB Shell 现已推出公共预览版 — 并且内置了 MCP 服务器

与其他数据库 CLI 的不同之处

开源基础很重要

三个变得更容易的场景

入门

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

winapp run：随处可用的F5

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

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

其他新功能

安装方式

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

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

管理正在运行的进程

与隔离模式结合使用

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

总结

azd update — 一个命令搞定所有包管理器

工作原理

一个小前提

为什么这很重要

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

问题是真实存在的

Aspire作为智能体基础设施

保龄球护栏类比

入门

总结

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

解决方案：--isolated

这个功能发光的真实场景

底层工作原理

何时使用

总结

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

这到底解决了什么问题

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

列出所有文档

搜索主题

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

AI 代理的视角

真实场景

文档始终是最新的

总结

解决方案：`--isolated`