Cli | The .NET Blog

dotnet new WinUI: Create Windows Apps Without Touching Visual Studio

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

WinUI development used to require Visual Studio. That’s changing: Microsoft has published open-source project and item templates for WinUI that work with dotnet new, bringing Windows app development into the standard CLI workflow.

Getting Started in Three Commands

# Install the templates
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates

# Create a NavigationView app
dotnet new winui-navview -n MyApp

# Run it
cd MyApp
dotnet run

No Visual Studio, no manual project setup. The app runs from dotnet run.

What’s Included

Blank template (dotnet new winui) — a modern starting point with a Fluent title bar already wired up, updated default app icon with .ico asset, proper light/dark mode defaults. Better than the old blank template that left you configuring the basics yourself.

NavigationView template (dotnet new winui-navview) — the master-detail navigation pattern, fully wired up with a NavigationView, modern title bar, and multi-page navigation structure. Follows the standard Windows app silhouette for navigation-based apps. If you’re building anything with side navigation, start here.

Both templates follow the Windows app silhouettes — modern Fluent Design patterns for layout, navigation, and visual structure — out of the box.

Why This Matters for Non-Visual-Studio Developers

WinUI developers using VS Code, Rider, or command-line tooling have been underserved. The existing Visual Studio templates weren’t usable outside of VS — you had to manually recreate project structure and wire up the basics.

These templates are open source (see WindowsAppSDK PR #6407), developed from community feedback, and available now. Visual Studio support is in progress — these same templates will eventually work there too.

For teams that want to script their WinUI project setup, integrate it into CI, or just use an editor other than Visual Studio, this is a meaningful improvement.

Original post: Introducing dotnet new WinUI templates

Cosmos DB Shell Is in Public Preview — And It Has an MCP Server Built In

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

If you’ve ever had to bounce between a portal tab, an SDK sample, and a half-finished script just to answer one Cosmos DB question, you already know the friction this project is designed to remove.

Azure Cosmos DB Shell just entered public preview. It’s an open-source CLI with bash-like syntax and — the part that makes this interesting — an integrated MCP server.

What Makes This Different From Other Database CLIs

The CLI itself is useful: familiar commands, scripting support, CI/CD integration. That part is table stakes for a developer-focused database tool.

The interesting part is the MCP server integration. Every command the CLI exposes becomes available as an MCP tool that your AI agents can call. There’s no custom API layer, no integration code to write. Your agent can:

Navigate database hierarchies with cd, ls, pwd
Run SQL queries with query and get structured results back
Create and modify items with create item, update, rm
Manage databases and containers with mkdb, mkcon, rmdb, rmcon
Inspect current context with endpoint, pwd

The key shift: your agent isn’t talking to a Cosmos DB API — it’s talking to the same shell interface you use. The commands are deterministic, auditable, and open source so you can inspect exactly what’s happening.

The Open-Source Foundation Matters

This isn’t a black-box managed service. The shell is open source, which means:

Security teams can audit the implementation
Platform teams can fork and extend it for their specific standards
Developers can contribute improvements that benefit everyone

For enterprise teams adopting AI tooling, “can we see exactly how it works” is increasingly not an optional requirement. Open source here is a meaningful differentiator.

Three Scenarios That Become Easier

Intelligent data analysis — connect an agent to the shell, ask natural language questions, get structured query results. The agent handles the query construction; the shell handles execution.

Autonomous data management — workflows that need to create, update, or remove data in Cosmos DB can do so through the MCP tools without needing a custom integration.

Real-time monitoring and alerts — an agent can periodically query containers, compare results, and surface anomalies through whatever notification channel makes sense.

The MCP interface makes these scenarios composable with any AI platform that speaks MCP — not just Microsoft’s tooling.

Getting Started

The shell is in public preview. Install it, configure your Cosmos DB connection, and enable the MCP server. From there, any MCP-compatible agent host can discover and use the tools.

Original post: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Windows App Dev CLI v0.3: F5 from the Terminal and UI Automation for Agents

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

Visual Studio’s F5 experience is great. But having to open VS just to launch and debug a packaged Windows app is a bit much when you’re deep in a CI pipeline, running an automated workflow, or — increasingly — when an AI agent is doing the testing.

Windows App Development CLI v0.3 just shipped, and it addresses this directly with two headline features: winapp run and winapp ui.

winapp run: F5 from anywhere

winapp run takes an unpackaged app folder and a manifest, and does everything VS does for a debug launch: registers a loose package, launches the app, and preserves your LocalState across re-deploys.

# Build your app, then run it as a packaged app
winapp run ./bin/Debug

Works for WinUI, WPF, WinForms, Console, Avalonia, and more. The modes are designed for both developers and automated workflows:

--detach: Launch and return control to the terminal immediately. Good for CI/automation where you need the app running but don’t want to block.
--unregister-on-exit: Cleans up the registered package when the app closes. Clean test runs, no leftover state.
--debug-output: Captures OutputDebugString messages and exceptions in real time. When a crash happens, a minidump is captured and analyzed in-process — managed (.NET) crashes via ClrMD, native (C++/WinRT) crashes via DbgEng. Add --symbols to pull PDBs from the Microsoft Symbol Server.

This is the kind of setup that makes headless test runs and agent-driven validation actually work. An agent can now launch your app, interact with it, verify behavior, and clean up — all without Visual Studio.

New NuGet package: dotnet run for packaged apps

For .NET developers specifically, there’s a new NuGet package: Microsoft.Windows.SDK.BuildTools.WinApp.

Add it to your project (or let winapp init do it), and dotnet run handles the entire inner loop: build, prepare a loose-layout package, register with Windows, and launch — all in one step.

# Let winapp init set it up
winapp init

# Or install directly
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

Works with WinUI, WPF, WinForms, Console, Avalonia. No manual registration, no extra commands. Just dotnet run.

This is a big quality-of-life win. If you’ve been maintaining a Makefile or PowerShell script just to wire together the build-and-register-and-launch cycle, that’s now a solved problem.

winapp ui: UI Automation from the command line

This is the one that opens up agentic scenarios. winapp ui gives you full UI Automation access to any running Windows app — WPF, WinForms, Win32, Electron, WinUI3 — all from the terminal.

What you can do:

List all top-level windows
Walk the full UI Automation tree of any window
Find elements by name, type, or automation ID
Click, invoke, and set values
Take screenshots (per-window or multi-window composites)
Wait for elements to appear — useful for test synchronization

Combine winapp ui with winapp run and you have a complete build → launch → verify workflow from the terminal. An agent can run your app, inspect the UI state, interact with it programmatically, and validate the result. No Visual Studio, no test framework bootstrapping, no manual steps.

For those building CI pipelines that do actual UI validation on Windows desktop apps, this is genuinely useful.

Other bits worth noting

winapp unregister: The cleanup counterpart to winapp run. Removes a sideloaded dev package when you’re done.
winapp manifest add-alias: Adds a uap5:AppExecutionAlias so a packaged app can be launched by name from the terminal.
Tab completion: One command to set up completions for PowerShell, then every winapp command and option is tab-completable.
Package.appxmanifest by default: winapp init now creates Package.appxmanifest (VS convention) instead of appxmanifest.xml.

Get it

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

The CLI is in public preview. Check the GitHub repo for full docs, guides for .NET, C++, Electron, Rust, Flutter, and more — and to file issues. The original announcement has all the details.

Stop Babysitting Your Terminal: Aspire's Detached Mode Changes the Workflow

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

Every time you run an Aspire AppHost, your terminal is gone. Locked. Occupied until you Ctrl+C out of it. Need to run a quick command? Open another tab. Want to check logs? Another tab. It’s a small friction that adds up fast.

Aspire 13.2 fixes this. James Newton-King wrote up the full details, and honestly, this is one of those features that immediately changes how you work.

Detached mode: one command, terminal back

aspire start

That’s the shorthand for aspire run --detach. Your AppHost boots up in the background and you get your terminal back immediately. No extra tabs. No terminal multiplexer. Just your prompt, ready to go.

Managing what’s running

Here’s the thing — running in the background is only useful if you can actually manage what’s out there. Aspire 13.2 ships a full set of CLI commands for exactly that:

# 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

This turns the Aspire CLI into a proper process manager. You can start multiple AppHosts, check their status, tail their logs, and shut them down — all from a single terminal session.

Combine it with isolated mode

Detached mode pairs naturally with isolated mode. Want to run two instances of the same project in the background without port conflicts?

aspire start --isolated
aspire start --isolated

Each gets random ports, separate secrets, and its own lifecycle. Use aspire ps to see both, aspire stop to kill whichever you’re done with.

Why this is huge for coding agents

This is where it gets really interesting. A coding agent working in your terminal can now:

Start the app with aspire start
Query its state with aspire describe
Check logs with aspire logs to diagnose issues
Stop it with aspire stop when done

All without losing the terminal session. Before detached mode, an agent that ran your AppHost would lock itself out of its own terminal. Now it can start, observe, iterate, and clean up — exactly how you’d want an autonomous agent to work.

The Aspire team leaned into this. Running aspire agent init sets up an Aspire skill file that teaches agents these commands. So tools like Copilot’s coding agent can manage your Aspire workloads out of the box.

Wrapping up

Detached mode is a workflow upgrade disguised as a simple flag. You stop context-switching between terminals, agents stop blocking themselves, and the new CLI commands give you real visibility into what’s running. It’s practical, it’s clean, and it makes the daily development loop noticeably smoother.

Read the full post for all the details and grab Aspire 13.2 with aspire update --self.

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.

.NET Aspire 13.2 Wants to Be Your AI Agent's Best Friend

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

You know that moment when your AI coding agent writes some solid code, you get excited, and then it completely falls apart trying to actually run the thing? Port conflicts, phantom processes, wrong environment variables — suddenly your agent is burning tokens troubleshooting startup issues instead of building features.

The Aspire team just dropped a really thoughtful post about exactly this problem, and their answer is compelling: Aspire 13.2 is designed not just for humans, but for AI agents.

The problem is real

AI agents are incredible at writing code. But shipping a working full-stack app involves way more than generating files. You need to start services in the right order, manage ports, set environment variables, connect databases, and get feedback when things break. Right now, most agents handle all of this through trial-and-error — running commands, reading error output, trying again.

We layer on Markdown instructions, custom skills, and prompts to try to guide them, but those are unpredictable, can’t be compiled, and cost tokens just to parse. The Aspire team nailed the core insight: agents need compilers and structured APIs, not more Markdown.

Aspire as agent infrastructure

Here’s what Aspire 13.2 brings to the agentic development table:

Your entire stack in typed code. The AppHost defines your full topology — API, frontend, database, cache — in compilable TypeScript or C#:

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();

An agent can read this to understand app topology, add resources, wire up connections, and build to verify. The compiler tells it immediately if something is wrong. No guessing, no trial-and-error with config files.

One command to rule them all. Instead of agents juggling docker compose up, npm run dev, and database startup scripts, everything is just aspire start. All resources launch in the right order, on the right ports, with the right configuration. Long-running processes don’t hang the agent either — Aspire manages them.

Isolated mode for parallel agents. With --isolated, each Aspire run gets its own random ports and separate user secrets. Got multiple agents working across git worktrees? They won’t collide. This is huge for tools like VS Code’s background agents that spin up parallel environments.

Agent eyes through telemetry. Here’s where it gets really powerful. The Aspire CLI exposes full OpenTelemetry data during development — traces, metrics, structured logs. Your agent isn’t just reading console output and hoping for the best. It can trace a failing request across services, profile slow endpoints, and pinpoint exactly where things break. That’s production-grade observability in the development loop.

The bowling bumper analogy

The Aspire team uses a great analogy: think of Aspire as bowling lane bumpers for AI agents. If the agent isn’t perfect (and it won’t be), the bumpers keep it from throwing gutter balls. The stack definition prevents misconfiguration, the compiler catches errors, the CLI handles process management, and the telemetry provides the feedback loop.

Pair this with something like Playwright CLI, and your agent can actually use your app — clicking through flows, checking the DOM, seeing broken things in telemetry, fixing the code, restarting, and testing again. Build, run, observe, fix. That’s the autonomous development loop we’ve been chasing.

Getting started

New to Aspire? Install the CLI from get.aspire.dev and follow the getting started guide.

Already using Aspire? Run aspire update --self to get 13.2, then point your favorite coding agent at your repo. You might be surprised how much further it gets with Aspire’s guardrails in place.

Wrapping up

Aspire 13.2 isn’t just a distributed app framework anymore — it’s becoming essential agent infrastructure. Structured stack definitions, one-command startup, isolated parallel runs, and real-time telemetry give AI agents exactly what they need to go from writing code to shipping apps.

Read the full post from the Aspire team for all the details and demo videos.

Aspire's Isolated Mode Fixes the Port Conflict Nightmare for Parallel Development

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

If you’ve ever tried running two instances of the same project at the same time, you know the pain. Port 8080 is already in use. Port 17370 is taken. Kill something, restart, juggle environment variables — it’s a productivity killer.

This problem is getting worse, not better. AI agents create git worktrees to work independently. Background agents spin up separate environments. Developers checkout the same repo twice for feature branches. Every one of these scenarios hits the same wall: two instances of the same app fighting over the same ports.

Aspire 13.2 fixes this with a single flag. James Newton-King from the Aspire team wrote up the full details, and it’s one of those “why didn’t we have this sooner” features.

The fix: `--isolated`

aspire run --isolated

That’s it. Each run gets:

Random ports — no more collisions between instances
Isolated user secrets — connection strings and API keys stay separate per instance

No manual port reassignment. No environment variable juggling. Each run gets a fresh, collision-free environment automatically.

Real scenarios where this shines

Multiple checkouts. You’ve got a feature branch in one directory and a bugfix in another:

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

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

Both run without conflicts. The dashboard shows what’s running and where.

Background agents in VS Code. When Copilot Chat’s background agent creates a git worktree to work on your code independently, it may need to run your Aspire AppHost. Without --isolated, that’s a port collision with your primary worktree. With it, both instances just work.

The Aspire skill that ships with aspire agent init automatically instructs agents to use --isolated when working in worktrees. So Copilot’s background agent should handle this out of the box.

Integration tests alongside development. Need to run tests against a live AppHost while continuing to build features? Isolated mode gives each context its own ports and config.

How it works under the hood

When you pass --isolated, the CLI generates a unique instance ID for the run. This drives two behaviors:

Port randomization — instead of binding to predictable ports defined in your AppHost config, isolated mode picks random available ports for everything — the dashboard, service endpoints, all of it. Service discovery adjusts automatically, so services find each other regardless of which ports they land on.
Secret isolation — each isolated run gets its own user secrets store, keyed by the instance ID. Connection strings and API keys from one run don’t leak into another.

Your code doesn’t need any changes. Aspire’s service discovery resolves endpoints at runtime, so everything connects correctly regardless of port assignment.

When to use it

Use --isolated when running multiple instances of the same AppHost simultaneously — whether that’s parallel development, automated tests, AI agents, or git worktrees. For single-instance development where you prefer predictable ports, regular aspire run still works fine.

Wrapping up

Isolated mode is a small feature that solves a real, increasingly common problem. As AI-assisted development pushes us toward more parallel workflows — multiple agents, multiple worktrees, multiple contexts — the ability to just spin up another instance without fighting over ports is essential.

Read the full post for all the technical details and try it out with aspire update --self to get 13.2.

Aspire 13.2 Ships a Docs CLI — and Your AI Agent Can Use It Too

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

You know that moment when you’re deep in an Aspire AppHost, wiring up integrations, and you need to check exactly which parameters the Redis integration expects? You alt-tab to your browser, hunt through aspire.dev, squint at the API docs, then come back to your editor. Context lost. Flow broken.

Aspire 13.2 just shipped a fix for that. The aspire docs CLI lets you search, browse, and read official Aspire documentation directly from your terminal. And because it’s backed by reusable services, AI agents and skills can use the same commands to look up docs instead of hallucinating APIs that don’t exist.

The problem this actually solves

David Pine nails it in the original post: AI agents were terrible at helping developers build Aspire apps. They’d recommend dotnet run instead of aspire run, reference learn.microsoft.com for docs that live on aspire.dev, suggest outdated NuGet packages, and — my personal favorite — hallucinate APIs that don’t exist.

Why? Because Aspire was .NET-specific far longer than it’s been polyglot, and LLMs are working off training data that predates the latest features. When you give an AI agent the ability to actually look up the current docs, it stops guessing and starts being useful.

Three commands, zero browser tabs

The CLI is refreshingly simple:

List all docs

aspire docs list

Returns every documentation page available on aspire.dev. Need machine-readable output? Add --format Json.

Search for a topic

aspire docs search "redis"

Searches both titles and content with weighted relevance scoring. Same search engine that powers the documentation tooling internally. You get ranked results with titles, slugs, and relevance scores.

Read a full page (or just one section)

aspire docs get redis-integration

Streams the full page as markdown to your terminal. Need just one section?

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

Surgical precision. No scrolling through 500 lines. Just the part you need.

The AI agent angle

Here’s where it gets interesting for us developers building with AI tooling. The same aspire docs commands work as tools for AI agents — through skills, MCP servers, or simple CLI wrappers.

Instead of your AI assistant making up Aspire APIs based on stale training data, it can call aspire docs search "postgres", find the official integration docs, read the right page, and give you the documented approach. Real-time, current documentation — not what the model memorized six months ago.

The architecture behind this is intentional. The Aspire team built reusable services (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) rather than a one-off integration. That means the same search engine works for humans in the terminal, AI agents in your editor, and automation in your CI pipeline.

Real-world scenarios

Quick terminal lookups: You’re three files deep and need Redis config parameters. Two commands, ninety seconds, back to work:

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

AI-assisted development: Your VS Code skill wraps the CLI commands. You ask “Add a PostgreSQL database to my AppHost” and the agent looks up the real docs before answering. No hallucinations.

CI/CD validation: Your pipeline validates AppHost configurations against official documentation programmatically. --format Json output pipes cleanly to jq and other tools.

Custom knowledge bases: Building your own AI tooling? Pipe structured JSON output directly into your knowledge base:

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

No web scraping. No API keys. Same structured data the docs tooling uses internally.

The documentation is always live

This is the part I appreciate most. The CLI doesn’t download a snapshot — it queries aspire.dev with ETag-based caching. The moment the docs update, your CLI and any skill built on top of it reflects that. No stale copies, no “but the wiki said…” moments.

Wrapping up

aspire docs is one of those small features that solves a real problem cleanly. Humans get terminal-native documentation access. AI agents get a way to stop guessing and start referencing actual docs. And it’s all backed by the same source of truth.

If you’re building with .NET Aspire and haven’t tried the CLI yet, run aspire docs search "your-topic-here" and see how it feels. Then consider wrapping those commands into whatever AI skill or automation setup you’re using — your agents will thank you.

Check out David Pine’s deep dive on how the docs tooling came together, and the official CLI reference for all the details.

Cli | The .NET Blog

dotnet new WinUI: Create Windows Apps Without Touching Visual Studio

Getting Started in Three Commands

What’s Included

Why This Matters for Non-Visual-Studio Developers

Cosmos DB Shell Is in Public Preview — And It Has an MCP Server Built In

What Makes This Different From Other Database CLIs

The Open-Source Foundation Matters

Three Scenarios That Become Easier

Getting Started

Windows App Dev CLI v0.3: F5 from the Terminal and UI Automation for Agents

winapp run: F5 from anywhere

New NuGet package: dotnet run for packaged apps

winapp ui: UI Automation from the command line

Other bits worth noting

Get it

Stop Babysitting Your Terminal: Aspire's Detached Mode Changes the Workflow

Detached mode: one command, terminal back

Managing what’s running

Combine it with isolated mode

Why this is huge for coding agents

Wrapping up

azd update — One Command to Rule All Your Package Managers

How it works

The small catch

Why it matters

.NET Aspire 13.2 Wants to Be Your AI Agent's Best Friend

The problem is real

Aspire as agent infrastructure

The bowling bumper analogy

Getting started

Wrapping up

Aspire's Isolated Mode Fixes the Port Conflict Nightmare for Parallel Development

The fix: --isolated

Real scenarios where this shines

How it works under the hood

When to use it

Wrapping up

Aspire 13.2 Ships a Docs CLI — and Your AI Agent Can Use It Too

The problem this actually solves

Three commands, zero browser tabs

List all docs

Search for a topic

Read a full page (or just one section)

The AI agent angle

Real-world scenarios

The documentation is always live

Wrapping up

The fix: `--isolated`