Developer Tools | The .NET Blog

VS Code 1.119: OpenTelemetry for Agent Sessions, Browser Integration, and Security

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

VS Code 1.119 shipped May 6, 2026 (with a 1.119.1 security patch shortly after). The release focuses on agent observability, browser interaction, and reducing interruptions.

OpenTelemetry tracing for agent sessions

This is the standout feature for anyone running agents in production or debugging agentic workflows. Enable it with two settings:

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

Traces follow GenAI semantic conventions. Each agent request produces an invoke_agent root span with nested child spans: chat, execute_tool, and execute_hook. Token usage is reported per request — including cache read and cache creation counts.

Works with the local agent, Copilot CLI background agent, and the Claude agent. Any OTLP-compatible backend accepts the traces — the Aspire Dashboard standalone works well for local development.

Agents can now access browser tabs

Agents can request access to your integrated browser tabs — but it’s not automatic. You have to explicitly share a tab via the context picker, drag-and-drop, or suggested context. There’s a sharing button in the browser to revoke access. When an agent tries to open a new tab on the same domain as an already-open (unshared) tab, VS Code prompts you to reuse the existing tab instead.

Optimized token usage

An experimental lightweight model now handles agent todo-list management, keeping that housekeeping off the more expensive primary model. Reduces token burn on tasks that don’t need full reasoning capacity.

Trust & security

Fewer interruptions: VS Code 1.119 reduces prompts for network access requests and temp folder writes by agents. The 1.119.1 patch addresses specific security issues — worth updating if you haven’t.

Markdown preview quick-swap

Small but useful: you can now quickly swap the current editor to Markdown preview without navigating away.

VS Code Agents (Insiders preview)

The redesigned agent session UI — new repo picker (local/repos/remote), sub-session improvements, web + mobile polish, progress animations — is available in Insiders at insiders.vscode.dev/agents.

Full changelog: code.visualstudio.com/updates/v1_119.

Azure Data Studio Is Retired: Move Your Azure SQL Workflow to VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

Azure Data Studio retired on February 6, 2025, with support ending February 28, 2026 — the recommended replacement is VS Code with the MSSQL extension.

What to install

Three things to get started:

MSSQL extension — search “SQL Server (mssql)” in the VS Code Marketplace
SQL Database Projects extension — schema-as-code, build validation, guided publish
.NET 8 SDK — required by the build system; missing SDK is the most common first-run issue

Migrating your ADS connections and settings

The MSSQL extension ships an ADS Migration Toolkit that handles the one-time migration in a guided flow: saved connections, connection groups, settings, and key bindings are all imported automatically.

Restoring F5 muscle memory

ADS users rely on F5 to run queries. Install the MSSQL Database Management Keymap extension to get ADS-style key bindings back, including F5.

SQL Database Projects: schema as code

Right-click a project → Publish → configure target → review the generated T-SQL script → deploy. The script preview before deployment is the key safety feature. Item templates generate stubs for tables, stored procedures, and views — the same workflow as SSDT.

Common gotcha: a target platform mismatch in the .sqlproj file will cause build errors if the project was created against a different SQL Server version.

Schema Compare and Schema Designer

The extension also includes Schema Compare (diff your project against the deployed database) and Schema Designer (visual schema editing without writing DDL by hand).

Microsoft Fabric developers

The setup is identical, but start from the Fabric portal and connect the database to Git first before opening it in VS Code. Microsoft has a dedicated guide: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Wrapping up

The migration is a one-time guided flow, not a manual rebuild. Install the three tools, run the ADS Migration Toolkit, restore your key bindings, and you’re back to normal in under 10 minutes.

See the full article for step-by-step screenshots and the Fabric-specific walkthrough.

Azure MCP Server Is Now a .mcpb — Install It Without Any Runtime

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

You know what was annoying about setting up MCP servers? You needed a runtime. Node.js for the npm version, Python for pip/uvx, .NET SDK for the dotnet flavor, Docker if you wanted containers. Just to get a tool connected to your AI client.

The Azure MCP Server just changed that. It’s now available as an .mcpb — an MCP Bundle — and the setup is drag-and-drop.

What’s an MCP Bundle?

Think of it like a VS Code extension (.vsix) or a browser extension (.crx), but for MCP servers. A .mcpb file is a self-contained ZIP archive that includes the server binary and all its dependencies. Everything needed to run on your platform, packaged together.

The end result: you download one file, open it in a supported client, and the server runs. No runtime to install, no package.json to manage, no version conflicts.

How to install it

Three steps:

1. Download the bundle for your platform

Go to the GitHub Releases page and grab the .mcpb file for your OS and architecture. Make sure you pick the right one — osx-arm64 for Apple Silicon, osx-x64 for Intel Mac, etc.

2. Install in Claude Desktop

The easiest way: drag and drop the .mcpb file into the Claude Desktop window while you’re on the Extensions settings page (☰ → File → Settings → Extensions). Review the server details, click Install, confirm. Done.

Tip: You can also set Claude Desktop as the default app for .mcpb files and double-click to install.

3. Authenticate to Azure

az login

That’s it. The Azure MCP Server uses your existing Azure credentials.

What you can do with it

Once installed, you have access to 100+ Azure service tools directly from your AI client:

Query and manage Cosmos DB, Storage, Key Vault, App Service, Foundry
Generate az CLI commands for any task
Create Bicep and Terraform templates
Get architecture recommendations and diagnostics

Try prompts like:

“List all resource groups in my subscription”
“Generate a Bicep template for a web app with a SQL database”
“What Cosmos DB databases do I have?”
“Show me the secrets in my Key Vault named my-vault”

Which install method should you use?

Method	Best for
`.mcpb`	Claude Desktop users who want zero-config
VS Code Extension	Developers working in VS Code + GitHub Copilot
npm/npx	Developers who already have Node.js
pip/uvx	Python developers
Docker	CI/CD pipelines and containers

All methods give you the same tools. The .mcpb is just the most frictionless path for Claude Desktop users.

Why this matters

MCP servers are genuinely useful — they let AI clients interact with external systems in a structured way. But the setup friction has been a real barrier, especially for users who aren’t developers or who just don’t want to manage runtimes for every tool they install.

The .mcpb format feels like the right direction. It’s the same principle as VS Code extensions or browser extensions: one file, platform-native binary, install and go.

If the MCP ecosystem keeps moving this direction, connecting AI clients to services will get a lot simpler.

Get started

Download: GitHub Releases
Repo: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Check the full post for troubleshooting tips and a comparison of all install methods.

VS Code 1.118: Copilot CLI Gets Session Names, Model Badges, and TypeScript 7.0 Nightly Opt-In

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

Visual Studio Code 1.118 is a smaller focused release — mostly Copilot CLI refinements — but there are a few things worth noting if you use the Agents app or TypeScript heavily.

Copilot CLI: sessions get real names

The Copilot CLI SDK session-title APIs are now used as the source of truth for session names. Previously you’d get auto-generated labels; now sessions surface the actual name from the SDK. Small quality-of-life improvement but it makes navigating multiple agent sessions a lot less confusing.

Switch sessions faster with keyboard shortcuts

The Agents app now has Ctrl+1, Ctrl+2, etc. bound to quickly switch between sessions. If you’re running multiple Copilot CLI sessions in parallel (which, if you’re doing agent-heavy work, you probably are), this removes a lot of mouse clicking.

Model badges in chat

Copilot CLI responses in the chat panel now show a model badge — you can see at a glance which model handled each request. Useful when you’re experimenting with different models in the same session.

Auto model selection lands in Copilot CLI

The auto model selection feature — previously available in other parts of Copilot — now works in the Copilot CLI agent too. Let the system pick the best model for the task rather than manually switching.

TypeScript 7.0 nightly opt-in

This one’s interesting if you’re on the TypeScript cutting edge: you can now opt in to testing TypeScript 7.0 nightlies directly from VS Code settings. TypeScript 7.0 is a major release with significant changes (the beta dropped a few days ago), and the opt-in path makes it easy to test without changing your global TypeScript install.

Under the hood: `node-pty` cleanup

The Copilot CLI SDK now resolves node-pty from VS Code via hostRequire instead of copying binaries into the SDK’s prebuilds folder at build time. This is an internal change but it simplifies distribution and means fewer things that can go wrong at runtime.

Wrapping up

Not a splashy release, but the Copilot CLI improvements add up — especially session management for anyone doing agent-heavy development. The TypeScript 7.0 nightly opt-in is a nice touch for those who like living on the edge.

See the full release notes for the complete change list.

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.

Foundry Toolboxes: One Endpoint for All Your Agent Tools

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

Here’s a problem that sounds boring until you’ve actually hit it: your organization is building multiple AI agents, each one needs tools, and every team is wiring those tools up from scratch. Same Web Search integration, same Azure AI Search config, same GitHub MCP server connection — just in a different repo, by a different team, with different credentials and no shared governance.

Microsoft Foundry just shipped Toolboxes in public preview, and it’s a direct answer to that problem.

What’s a Toolbox?

A Toolbox is a named, reusable bundle of tools that you define once in Foundry and expose through a single MCP-compatible endpoint. Any agent runtime that speaks MCP can consume it — you’re not locked to Foundry Agents.

The pitch is simple: build once, consume anywhere. Define the tools, configure auth centrally (OAuth passthrough, Entra managed identity), publish the endpoint. Every agent that needs those tools connects to the endpoint and gets them all.

No per-tool wiring. No per-agent credential management.

The four pillars (two of which ship today)

The Toolbox feature is organized around four ideas:

Pillar	Status	What it does
Discover	Coming soon	Find existing approved tools without hunting
Build	Available now	Curate tools into a named, reusable bundle
Consume	Available now	Single MCP endpoint exposes all tools
Govern	Coming soon	Centralized auth + observability across all tool calls

Today the focus is on Build and Consume. That’s enough to remove the most immediate friction.

Getting started in practice

The SDK is Python-first for now. You start by creating an AIProjectClient and then build a toolbox:

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

Then you create a toolbox version with the tools you want to bundle:

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Search public and internal docs, then respond to GitHub issues.",
 tools=[
 {"type": "web_search", "description": "Search approved public documentation"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Once published, Foundry gives you a unified endpoint:

https://zava.services.ai.azure.com/api/projects/<project>/toolbox/<toolbox-name>/mcp?api-version=v1

Point any MCP-compatible agent runtime at that URL and it discovers all the tools in the bundle dynamically. One connection. All tools.

Not locked to Foundry Agents

This is worth spelling out because it’s a common concern when Microsoft ships something under the Foundry brand.

Toolboxes are created and governed in Foundry, but the consumption surface is the open MCP protocol. That means you can use them from:

Custom agents built with Microsoft Agent Framework, LangGraph, or your own code
GitHub Copilot and other MCP-enabled IDEs
Any other runtime that speaks MCP

You’re not locked in. The toolbox is Foundry-homed (that’s where you manage it) but not Foundry-bound (you can consume it from anywhere).

Why it matters now

The multi-agent wave is hitting production. Teams are building 5, 10, 20 agents — and the tool-wiring problem compounds fast. Every new agent is a new surface for duplicated config, stale credentials, and inconsistent behavior.

Toolboxes don’t solve governance and discovery yet (those are “coming soon”), but the Build + Consume foundation is enough to start centralizing. Once the Govern pillar ships, you’ll have a proper observable, centrally-controlled tool layer for your entire agent fleet.

Wrapping up

This is early — public preview, Python SDK first, with Discover and Govern still coming. But the model is sound, and the MCP-native design means it works with the tools you’re already building on. Take a look at the official announcement to get started.

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.

VS Code 1.117: Agents Are Getting Their Own Git Branches and I'm Here For It

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

The line between “AI assistant” and “AI teammate” keeps getting thinner. VS Code 1.117 just dropped and the full release notes are packed, but the story here is clear: agents are becoming first-class citizens in your dev workflow.

Here’s what actually matters.

Autopilot mode finally remembers your preference

Previously, you had to re-enable Autopilot every time you started a new session. Annoying. Now your permission mode persists across sessions, and you can configure the default.

The Agent Host supports three session configs:

Default — tools ask for confirmation before running
Bypass — auto-approves everything
Autopilot — fully autonomous, answers its own questions and keeps going

If you’re scaffolding a new .NET project with migrations, Docker, and CI — set it to Autopilot once and forget about it. That preference sticks.

Worktree and git isolation for agent sessions

This is the big one. Agent sessions now support full worktree and git isolation. That means when an agent works on a task, it gets its own branch and working directory. Your main branch stays untouched.

Even better — Copilot CLI generates meaningful branch names for these worktree sessions. No more agent-session-abc123. You get something that actually describes what the agent is doing.

For .NET developers running multiple feature branches or fixing bugs while a long scaffolding task runs, this is a game changer. You can have an agent building out your API controllers in one worktree while you’re debugging a service layer issue in another. No conflicts. No stashing. No mess.

Subagents and agent teams

The Agent Host Protocol now supports subagents. An agent can spin up other agents to handle parts of a task. Think of it as delegating — your main agent coordinates, and specialized agents handle the pieces.

This is early, but the potential for .NET workflows is obvious. Imagine one agent handling your EF Core migrations while another sets up your integration tests. We’re not fully there yet, but the protocol support landing now means tooling will follow fast.

Terminal output auto-included when agents send input

Small but meaningful. When an agent sends input to the terminal, the terminal output is now automatically included in the context. Before, the agent had to make an extra turn just to read what happened.

If you’ve ever watched an agent run dotnet build, fail, and then take another round-trip just to see the error — that friction is gone. It sees the output immediately and reacts.

Self-updating Agents app on macOS

The standalone Agents app on macOS now self-updates. No more manually downloading new versions. It just stays current.

The smaller stuff worth knowing

package.json hovers now show both the installed version and the latest available. Useful if you manage npm tooling alongside your .NET projects.
Images in JSDoc comments render correctly in hovers and completions.
Copilot CLI sessions now indicate whether they were created by VS Code or externally — handy when you’re jumping between terminals.
Copilot CLI, Claude Code, and Gemini CLI are recognized as shell types. The editor knows what you’re running.

The takeaway

VS Code 1.117 isn’t a flashy feature dump. It’s infrastructure. Worktree isolation, persistent permissions, subagent protocols — these are the building blocks for a workflow where agents handle real, parallel tasks without stepping on your code.

If you’re building with .NET and haven’t leaned into the agentic workflow yet, honestly, now’s the time to start.

Docker Sandbox Lets Copilot Agents Refactor Your Code Without Risking Your Machine

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

If you’ve used Copilot’s agent mode for anything beyond small edits, you know the pain. Every file write, every terminal command — another permission prompt. Now imagine running that across 50 projects. Not fun.

The Azure team just dropped a post about Docker Sandbox for GitHub Copilot agents, and honestly, this is one of the most practical agentic tooling improvements I’ve seen. It uses microVMs to give Copilot a fully isolated environment where it can go wild — install packages, run builds, execute tests — without touching your host system.

What Docker Sandbox actually gives you

The core idea is simple: spin up a lightweight microVM with a full Linux environment, sync your workspace into it, and let the Copilot agent operate freely inside. When it’s done, changes sync back.

Here’s what makes it more than just “run stuff in a container”:

Bidirectional workspace sync that preserves absolute paths. Your project structure looks identical inside the sandbox. No path-related build failures.
Private Docker daemon running inside the microVM. The agent can build and run containers without ever mounting your host’s Docker socket. That’s a big deal for security.
HTTP/HTTPS filtering proxies that control what the agent can reach on the network. You decide which registries and endpoints are allowed. Supply chain attacks from a rogue npm install inside the sandbox? Blocked.
YOLO mode — yes, that’s what they call it. The agent runs without permission prompts because it literally cannot damage your host. Every destructive action is contained.

Why .NET developers should care

Think about the modernization work so many teams are facing right now. You have a .NET Framework solution with 30 projects, and you need to move it to .NET 9. That’s hundreds of file changes — project files, namespace updates, API replacements, NuGet migrations.

With Docker Sandbox, you can point a Copilot agent at a project, let it refactor freely inside the microVM, run dotnet build and dotnet test to validate, and only accept the changes that actually work. No risk of it accidentally nuking your local dev environment while experimenting.

The post also describes running a fleet of parallel agents — each in its own sandbox — tackling different projects simultaneously. For large .NET solutions or microservice architectures, that’s a massive time saver. One agent per service, all running isolated, all validated independently.

The security angle matters

Here’s the thing most people skip over: when you let an AI agent execute arbitrary commands, you’re trusting it with your entire machine. Docker Sandbox flips that model. The agent gets full autonomy inside a throwaway environment. The network proxy ensures it can only pull from approved sources. Your host filesystem, Docker daemon, and credentials stay untouched.

For teams with compliance requirements — and that’s most enterprise .NET shops — this is the difference between “we can’t use agentic AI” and “we can adopt it safely.”

Takeaway

Docker Sandbox solves the fundamental tension of agentic coding: agents need freedom to be useful, but freedom on your host machine is dangerous. MicroVMs give you both. If you’re planning any large-scale .NET refactoring or modernization, this is worth setting up now. The combination of Copilot’s code intelligence with a safe execution environment is exactly what production teams have been waiting for.

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.

Azure MCP Tools Are Now Baked Into Visual Studio 2022 — No Extension Required

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

If you’ve been using the Azure MCP tools in Visual Studio through the separate extension, you know the drill — install the VSIX, restart, hope it doesn’t break, manage version mismatches. That friction is gone.

Yun Jung Choi announced that Azure MCP tools now ship directly as part of the Azure development workload in Visual Studio 2022. No extension. No VSIX. No restart dance.

What this actually means

Starting with Visual Studio 2022 version 17.14.30, the Azure MCP Server is bundled with the Azure development workload. If you already have that workload installed, you just need to toggle it on in GitHub Copilot Chat and you’re done.

Over 230 tools across 45 Azure services — accessible directly from the chat window. List your storage accounts, deploy an ASP.NET Core app, diagnose App Service issues, query Log Analytics — all without opening a browser tab.

Why this matters more than it sounds

Here’s the thing about developer tooling: every extra step is friction, and friction kills adoption. Having MCP as a separate extension meant version mismatches, installation failures, and one more thing to keep updated. Baking it into the workload means:

Single update path through the Visual Studio Installer
No version drift between the extension and the IDE
Always current — the MCP Server updates with regular VS releases

For teams standardizing on Azure, this is a big deal. You install the workload once, enable the tools, and they’re there for every session.

What you can do with it

The tools cover the full development lifecycle through Copilot Chat:

Learn — ask about Azure services, best practices, architecture patterns
Design & develop — get service recommendations, configure app code
Deploy — provision resources and deploy directly from the IDE
Troubleshoot — query logs, check resource health, diagnose production issues

A quick example — type this in Copilot Chat:

List my storage accounts in my current subscription.

Copilot calls the Azure MCP tools behind the scenes, queries your subscriptions, and returns a formatted list with names, locations, and SKUs. No portal needed.

How to enable it

Update to Visual Studio 2022 17.14.30 or higher
Make sure the Azure development workload is installed
Open GitHub Copilot Chat
Click the Select tools button (the two wrenches icon)
Toggle Azure MCP Server on

That’s it. It stays enabled across sessions.

One caveat

The tools are disabled by default — you need to opt in. And VS 2026-specific tools aren’t available in VS 2022. Tool availability also depends on your Azure subscription permissions, same as the portal.

The bigger picture

This is part of a clear trend: MCP is becoming the standard way to surface cloud tools in developer IDEs. We’ve already seen the Azure MCP Server 2.0 stable release and MCP integrations across VS Code and other editors. Having it built into Visual Studio’s workload system is the natural progression.

For us .NET developers who live in Visual Studio, this removes yet another reason to context-switch to the Azure portal. And honestly, the less tab-switching, the better.

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.

That Visual Studio Floating Windows Setting You Didn't Know About (But Should)

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

If you use multiple monitors with Visual Studio (and honestly, who doesn’t these days), you’ve probably experienced the annoyance: floating tool windows disappear when you minimize the main IDE, they always stay on top of everything else, and they don’t show up as separate taskbar buttons. It works for some workflows, but for multi-monitor setups it’s frustrating.

Mads Kristensen from the Visual Studio team shared a little-known setting that completely changes how floating windows behave. One dropdown. That’s it.

The setting

Tools > Options > Environment > Windows > Floating Windows

The dropdown “These floating windows are owned by the main window” has three options:

None — full independence. Every floating window gets its own taskbar entry and behaves like a normal Windows window.
Tool Windows (default) — documents float freely, tool windows stay tied to the IDE.
Documents and Tool Windows — classic Visual Studio behavior, everything tied to the main window.

Why “None” is the move for multi-monitor setups

Set it to None and suddenly all your floating tool windows and documents behave like real Windows applications. They appear in the taskbar, stay visible when you minimize the main Visual Studio window, and stop forcing themselves to the front of everything.

Combine this with PowerToys FancyZones and it’s a game changer. Create custom layouts across your monitors, snap your Solution Explorer to one zone, debugger to another, and code files wherever you want. Everything stays put, everything is independently accessible, and your workspace feels organized instead of chaotic.

Quick recommendations

Multi-monitor power users: Set to None, pair with FancyZones
Occasional floaters: Tool Windows (default) is a solid middle ground
Traditional workflow: Documents and Tool Windows keeps everything classic

Pro tip: Ctrl + double-click on any tool window title bar to instantly float or dock it. No restart needed after changing the setting.

Wrapping up

It’s one of those “I can’t believe I didn’t know about this” settings. If floating windows in Visual Studio have ever annoyed you, go change this right now.

Read the full post for the details and screenshots.

VS Code 1.116 — Agents App Gets Keyboard Navigation and File Context Completions

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

VS Code 1.116 is the April 2026 release, and while it’s lighter than some recent updates, the changes are focused and meaningful — especially if you’re using the Agents app daily.

Here’s what landed, based on the official release notes.

Agents app improvements

The Agents app continues to mature with usability polish that makes a real difference in daily workflows:

Dedicated keybindings — you can now focus the Changes view, the files tree within Changes, and the Chat Customizations view with dedicated commands and keyboard shortcuts. If you’ve been clicking around the Agents app to navigate, this brings full keyboard-driven workflows.

Accessibility help dialog — pressing Alt+F1 in the chat input box now opens an accessibility help dialog showing available commands and keybindings. Screen reader users can also control announcement verbosity. Good accessibility benefits everyone.

File-context completions — type # in the Agents app chat to trigger file-context completions scoped to your current workspace. This is one of those small quality-of-life improvements that speeds up every interaction — no more typing full file paths when referencing code.

CSS `@import` link resolution

A nice one for frontend developers: VS Code now resolves CSS @import references that use node_modules paths. You can Ctrl+click through imports like @import "some-module/style.css" when using bundlers. Small but eliminates a friction point in CSS workflows.

Wrapping up

VS Code 1.116 is about refinement — making the Agents app more navigable, more accessible, and more keyboard-friendly. If you’re spending significant time in the Agents app (and I suspect many of us are), these changes add up.

Check the full release notes for the complete list.

VS Code 1.115 — Background Terminal Notifications, SSH Agent Mode, and More

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 just dropped, and while it’s a lighter release in terms of headline features, the agent-related improvements are genuinely useful if you’re working with AI coding assistants daily.

Let me highlight what’s actually worth knowing.

Background terminals talk back to agents

This is the standout feature. Background terminals now automatically notify agents when commands complete, including the exit code and terminal output. Input prompts in background terminals are also detected and surfaced to the user.

Why does this matter? If you’ve used Copilot’s agent mode to run build commands or test suites in the background, you know the pain of “did that finish yet?” — background terminals were essentially fire-and-forget. Now the agent gets notified when your dotnet build or dotnet test completes, sees the output, and can react accordingly. It’s a small change that makes agent-driven workflows significantly more reliable.

There’s also a new send_to_terminal tool that lets agents send commands to background terminals with user confirmation, fixing the issue where run_in_terminal with a timeout would move terminals to the background and make them read-only.

SSH remote agent hosting

VS Code now supports connecting to remote machines over SSH, automatically installing the CLI and starting it in agent host mode. This means your AI agent sessions can target remote environments directly — useful for .NET developers who build and test on Linux servers or cloud VMs.

Edit tracking in agent sessions

File edits made during agent sessions are now tracked and restored, with diffs, undo/redo, and state restoration. If an agent makes changes to your code and something goes wrong, you can see exactly what changed and roll it back. Peace of mind for letting agents modify your codebase.

Browser tab awareness and other improvements

A few more quality-of-life additions:

Browser tab tracking — chat can now track and link to browser tabs opened during a session, so agents can reference web pages you’re looking at
File paste in terminal — paste files (including images) into the terminal with Ctrl+V, drag-and-drop, or right-click
Test coverage in minimap — test coverage indicators now show in the minimap for a quick visual overview
Pinch-to-zoom on Mac — integrated browser supports pinch-to-zoom gestures
Copilot entitlements in Sessions — status bar shows usage info in the Sessions view
Favicon in Go to File — open web pages show favicons in the quick pick list

Wrapping up

VS Code 1.115 is an incremental release, but the agent improvements — background terminal notifications, SSH agent hosting, and edit tracking — add up to a noticeably smoother experience for AI-assisted development. If you’re using Copilot’s agent mode for .NET projects, these are the kinds of quality-of-life fixes that reduce friction daily.

Check out the full release notes for every detail.

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.

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.

Azure DevOps Finally Fixes the Markdown Editor UX Everyone Complained About

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

If you use Azure Boards, you’ve probably experienced this: you’re reading through a work item description, maybe reviewing acceptance criteria, and you accidentally double-click. Boom — you’re in edit mode. You didn’t want to edit anything. You were just reading.

Dan Hellem announced the fix, and it’s one of those changes that sounds tiny but actually removes real friction from your daily workflow.

What changed

The Markdown editor for work item text fields now opens in preview mode by default. You can read and interact with the content — follow links, review formatting — without worrying about accidentally entering edit mode.

When you actually want to edit, you click the edit icon at the top of the field. When you’re done, you exit back to preview mode explicitly. Simple, intentional, predictable.

That’s it. That’s the change.

Why this matters more than it sounds

The community feedback thread on this was long. The double-click-to-edit behavior was introduced with the Markdown editor back in July 2025, and the complaints started almost immediately. The problem wasn’t just accidental edits — it was that the whole interaction felt unpredictable. You never knew if clicking would read or edit.

For teams that do sprint planning, backlog grooming, or code review with Azure Boards, this kind of micro-friction compounds. Every accidental edit mode entry is a context switch. Every “wait, did I change something?” moment is wasted attention.

The new default respects the most common interaction pattern: you read work items far more often than you edit them.

Rollout status

This is already rolling out to a subset of customers and expanding to everyone over the next two to three weeks. If you’re not seeing it yet, you will soon.

Wrapping up

Not every improvement needs to be a headline feature. Sometimes the best update is just removing something annoying. This is one of those — a small UX fix that makes Azure Boards feel less hostile to people who just want to read their work items in peace.

Bookmark Studio Brings Slot-Based Navigation and Sharing to Visual Studio Bookmarks

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

Bookmarks in Visual Studio have always been… fine. You set one, you navigate to the next, you forget which bookmark is which. They work, but they’ve never been the kind of feature you’d call powerful.

Mads Kristensen just released Bookmark Studio, an experimental extension that fills in exactly the gaps you’ve probably run into if you use bookmarks regularly.

The core addition: bookmarks can now be assigned to slots 1–9 and jumped to directly with Alt+Shift+1 through Alt+Shift+9. New bookmarks automatically get the next available slot, so in most cases, fast navigation works without any setup.

This sounds simple, but it changes bookmarks from “I have some bookmarks somewhere” to “Slot 3 is my API controller, Slot 5 is the service layer, Slot 7 is the test.” That kind of spatial memory makes navigation nearly instant during focused work sessions.

The Bookmark Manager

A new tool window shows all your bookmarks in one place with filtering by name, file, location, color, or slot. Double-click or keyboard-navigate to jump to any bookmark.

If you’ve ever had more than five or six bookmarks and lost track of which was which, this alone is worth installing the extension.

Organization with labels, colors, and folders

Bookmarks can optionally have labels, colors, and be grouped into folders. None of it is required — your current bookmark workflow keeps working. But when you’re debugging a complex issue or exploring an unfamiliar codebase, being able to color-code and label your bookmarks adds useful context.

All metadata is stored per solution, so your bookmark organization persists across sessions.

This is the feature I didn’t know I wanted. Bookmark Studio lets you export bookmarks as plain text, Markdown, or CSV. That means you can:

Include bookmark paths in pull request descriptions
Share investigation breadcrumbs with teammates
Move bookmark sets between repos or branches

Bookmarks stop being a solo navigation tool and start being a way to communicate “here’s the path through this code.”

Bookmarks that track code movement

Bookmark Studio tracks bookmarks relative to the text they’re anchored to, so they don’t drift to wrong lines as you edit. If you’ve ever set bookmarks during a debugging session and had them all point to the wrong lines after a refactor — this fixes that.

Wrapping up

Bookmark Studio doesn’t reinvent anything. It takes a feature that’s been “good enough” for years and makes it genuinely useful for focused development. Slot navigation, the Bookmark Manager, and export capabilities are the highlights.

Grab it from the Visual Studio Marketplace and give it a try.

Visual Studio's March Update Lets You Build Custom Copilot Agents — and the find_symbol Tool Is a Big Deal

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

Visual Studio just got its most significant Copilot update yet. Mark Downie announced the March release, and the headline is custom agents — but honestly, the find_symbol tool buried further down might be the feature that changes your workflow the most.

Let me break down what’s actually here.

Custom Copilot agents in your repo

Want Copilot to follow your team’s coding standards, run your build pipeline, or query your internal docs? Now you can build exactly that.

Custom agents are defined as .agent.md files that you drop into .github/agents/ in your repository. Each agent gets full access to workspace awareness, code understanding, tools, your preferred model, and MCP connections to external services. They show up in the agent picker alongside the built-in agents.

This is the same pattern VS Code has been supporting — and it’s great to see Visual Studio catch up. For teams that have already built agents for VS Code, your .agent.md files should work across both IDEs (though tool names can vary, so test them).

The awesome-copilot repo has community-contributed agent configurations you can use as starting points.

Agent skills: reusable instruction packs

Skills are automatically picked up from .github/skills/ in your repo or ~/.copilot/skills/ in your profile. Each skill is a SKILL.md file following the Agent Skills specification.

Think of skills as modular expertise you can mix and match. You might have a skill for your API conventions, another for your testing patterns, and another for your deployment workflow. When a skill activates, it shows up in the chat so you know it’s being applied.

If you’ve been using skills in VS Code, they work the same way in Visual Studio now.

This is where things get really interesting. The new find_symbol tool gives Copilot’s agent mode actual language-service-powered symbol navigation. Instead of searching your code as text, the agent can:

Find all references to a symbol across your project
Access type information, declarations, and scope metadata
Navigate call sites with full language awareness

What this means in practice: when you ask Copilot to refactor a method or update a parameter signature across call sites, it can actually see your code’s structure. No more “the agent changed the method but missed three call sites” situations.

Supported languages include C#, C++, Razor, TypeScript, and anything with a supported LSP extension. For .NET developers, this is a massive improvement — C# codebases with deep type hierarchies and interfaces benefit enormously from symbol-aware navigation.

Profile tests with Copilot

There’s now a Profile with Copilot command in the Test Explorer context menu. Select a test, click profile, and the Profiling Agent automatically runs it and analyzes performance — combining CPU usage and instrumentation data to deliver actionable insights.

No more manually configuring profiler sessions, running the test, exporting results, and trying to read a flame graph. The agent does the analysis and tells you what’s slow and why. Currently .NET only, which makes sense given Visual Studio’s deep .NET diagnostics integration.

Perf tips during live debugging

Performance optimization now happens while you debug, not after. As you step through code, Visual Studio shows execution time and performance signals inline. See a slow line? Click the Perf Tip and ask Copilot for optimization suggestions right there.

The Profiling Agent captures runtime data automatically — elapsed time, CPU usage, memory behavior — and Copilot uses it to pinpoint hot spots. This keeps performance work as part of your debugging flow instead of a separate task you keep postponing.

Fix NuGet vulnerabilities from Solution Explorer

When a vulnerability is detected in a NuGet package, you now see a notification with a Fix with GitHub Copilot link directly in Solution Explorer. Click through and Copilot analyzes the vulnerability, recommends the right package updates, and implements them.

For teams that struggle to keep dependencies up to date (which is basically everyone), this removes the friction of “I know there’s a vulnerability but figuring out the right update path is a project in itself.”

Wrapping up

Custom agents and skills are the headline, but find_symbol is the sleeper hit — it fundamentally changes how accurate Copilot can be when refactoring .NET code. Combined with live profiling integration and vulnerability fixes, this update makes Visual Studio’s AI features feel genuinely practical rather than demo-ready.

Download Visual Studio 2026 Insiders to try it all out.

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.

Developer Tools | The .NET Blog

VS Code 1.119: OpenTelemetry for Agent Sessions, Browser Integration, and Security

OpenTelemetry tracing for agent sessions

Agents can now access browser tabs

Optimized token usage

Trust & security

Markdown preview quick-swap

VS Code Agents (Insiders preview)

Azure Data Studio Is Retired: Move Your Azure SQL Workflow to VS Code

What to install

Migrating your ADS connections and settings

Restoring F5 muscle memory

SQL Database Projects: schema as code

Schema Compare and Schema Designer

Microsoft Fabric developers

Wrapping up

Azure MCP Server Is Now a .mcpb — Install It Without Any Runtime

What’s an MCP Bundle?

How to install it

What you can do with it

Which install method should you use?

Why this matters

Get started

VS Code 1.118: Copilot CLI Gets Session Names, Model Badges, and TypeScript 7.0 Nightly Opt-In

Copilot CLI: sessions get real names

Switch sessions faster with keyboard shortcuts

Model badges in chat

Auto model selection lands in Copilot CLI

TypeScript 7.0 nightly opt-in

Under the hood: node-pty cleanup

Wrapping up

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

Foundry Toolboxes: One Endpoint for All Your Agent Tools

What’s a Toolbox?

The four pillars (two of which ship today)

Getting started in practice

Not locked to Foundry Agents

Why it matters now

Wrapping up

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

VS Code 1.117: Agents Are Getting Their Own Git Branches and I'm Here For It

Autopilot mode finally remembers your preference

Worktree and git isolation for agent sessions

Subagents and agent teams

Terminal output auto-included when agents send input

Self-updating Agents app on macOS

The smaller stuff worth knowing

The takeaway

Docker Sandbox Lets Copilot Agents Refactor Your Code Without Risking Your Machine

What Docker Sandbox actually gives you

Why .NET developers should care

The security angle matters

Takeaway

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

Azure MCP Tools Are Now Baked Into Visual Studio 2022 — No Extension Required

What this actually means

Why this matters more than it sounds

What you can do with it

How to enable it

One caveat

The bigger picture

Under the hood: `node-pty` cleanup

The fix: `--isolated`

CSS `@import` link resolution

The new `azd ai agent` workflow