Visual Studio | The .NET Blog

Visual Studio 2026 April Update: Cloud Agent, Custom Agents, and Debugger Agent

Emiliano Montesdeoca — Thu, 14 May 2026 00:00:00 +0000

Visual Studio 2026 (18.5) April update ships cloud agent integration, user-level custom agents, C++ tools going GA, and a new Debugger Agent.

Cloud agent: offload work to a remote Copilot session

From the Chat window’s agent picker, selecting Cloud lets you hand off a task to a remote Copilot coding agent. You describe the work, the agent creates a GitHub issue in your repo, then opens a PR when done. You get a notification with “View PR” / “Open in browser” — the whole thing runs while you keep coding, or even with the IDE closed.

Custom agents now travel with you

User-level custom agents stored in %USERPROFILE%/.github/agents/ are no longer repo-scoped — they follow you across projects. The storage path is configurable under Tools > Options > GitHub > Copilot > Chat. The + button in the agent picker lets you create new agents directly. They get the same capabilities as repo-scoped agents: workspace awareness, tools, model selection, and MCP connections.

Built-in agents: Agent, Ask, Copilot CLI, Debugger, Modernize, Profiler.

C++ Code Editing Tools go GA

Two tools — get_symbol_call_hierarchy and get_symbol_class_hierarchy — are now on by default. They give Copilot language-aware navigation of C++ codebases, covering inheritance hierarchies and function call chains. Enable via the Tools icon in Copilot Chat. Works best with tool-calling models.

Debugger Agent: fixes validated against real runtime behavior

Start from a GitHub or Azure DevOps issue (or just a natural language description), switch to Debugger mode, and the agent:

Creates a minimal reproducer
Generates failure hypotheses
Instruments the app with tracepoints and conditional breakpoints
Runs an actual debug session
Analyzes live telemetry
Suggests a precise fix

You stay in the loop throughout — it’s interactive, not fully autonomous.

IntelliSense priority fix

VS now suppresses Copilot completions while the IntelliSense list is active. One suggestion at a time. This was a frequent friction point and it’s now on by default.

Full release notes and download at devblogs.microsoft.com.

SDK-Style Support for Extension Projects in Visual Studio

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

SDK-Style support for VSSDK-based extension projects is now officially in Visual Studio 18.5 — classic VSIX extension projects can ditch the old MPF-style .csproj format.

What changes in the project file

The biggest visible change is how much smaller the project file gets. A typical VSSDK extension now looks like this:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net472</TargetFramework>
 <VSSDKBuildToolsAutoSetup>true</VSSDKBuildToolsAutoSetup>
 <VsixDeployOnDebug>true</VsixDeployOnDebug>
 <GeneratePkgDefFile>true</GeneratePkgDefFile>
 </PropertyGroup>
 <ItemGroup><ProjectCapability Include="CreateVsixContainer" /></ItemGroup>
 <ItemGroup>
 <PackageReference Include="Microsoft.VisualStudio.SDK" Version="17.14.40265" ExcludeAssets="runtime" />
 <PackageReference Include="Microsoft.VSSDK.BuildTools" Version="18.5.38461" />
 </ItemGroup>
</Project>

VSSDKBuildToolsAutoSetup=true applies sensible defaults: CreateVsixContainer=true and legacy DeployExtension=false. That single property replaces a significant chunk of what previously had to be spelled out explicitly.

Build time improvements

Fast Up-To-Date Check and incremental build support are included. For large solutions with small changes, this translates to up to 75% build time reduction — meaningful if you’re iterating on an extension inside a large host solution.

New projects vs existing

New extension projects created in 18.5 automatically use SDK-style. Existing MPF-style extensions keep working — migration is opt-in. One thing to watch during migration: add <UseWpf>true</UseWpf> if your extension uses XAML. You also need to mark the extension as deployable in your .sln or .slnx file.

The vsixmanifest designer is replaced by the XML editor as the default — right-click → Open With if you want the old designer back.

Agentic migration path

The Modernize agent in vs-agent-plugins can automate the migration. Several real extensions have already been converted this way: Mads Kristensen’s Smart Screen, Command Explorer, Postfix Templates, and Whitespace Visualizer.

Worth noting

VisualStudio.Extensibility (the newer extensibility framework) already supported SDK-style. This update brings parity to the classic VSSDK path. The only requirement is the Visual Studio extension development workload.

Full details in the official post.

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.

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.

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.

VS Code 1.112: What .NET Developers Should Actually Care About

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

VS Code 1.112 just landed, and honestly? This one hits different if you’re spending your days in .NET land. There’s a lot in the official release notes, but let me save you some scrolling and focus on what actually matters for us.

Copilot CLI just got way more useful

The big theme this release is agent autonomy — giving Copilot more room to do its thing without you babysitting every step.

Message steering and queueing

You know that moment when Copilot CLI is halfway through a task and you realize you forgot to mention something? Before, you had to wait. Now you can just send messages while a request is still running — either to steer the current response or queue up follow-up instructions.

This is huge for those longer dotnet scaffolding tasks where you’re watching Copilot set up a project and think “oh wait, I also need MassTransit in there.”

Permission levels

This is the one I’m most excited about. Copilot CLI sessions now support three permission levels:

Default Permissions — the usual flow where tools ask for confirmation before running
Bypass Approvals — auto-approves everything and retries on errors
Autopilot — goes fully autonomous: approves tools, answers its own questions, and keeps going until the task is done

If you’re doing something like scaffolding a new ASP.NET Core API with Entity Framework, migrations, and a Docker setup — Autopilot mode means you describe what you want and go grab a coffee. It’ll figure it out.

You can enable Autopilot with the chat.autopilot.enabled setting.

Preview changes before delegation

When you delegate a task to Copilot CLI, it creates a worktree. Before, if you had uncommitted changes, you had to check Source Control to see what would be affected. Now the Chat view shows pending changes right there before you decide whether to copy, move, or ignore them.

Small thing, but it saves you from that “wait, what did I have staged?” moment.

Debug web apps without leaving VS Code

The integrated browser now supports full debugging. You can set breakpoints, step through code, and inspect variables — all inside VS Code. No more switching to Edge DevTools.

There’s a new editor-browser debug type, and if you already have existing msedge or chrome launch configurations, migrating is as simple as changing the type field in your launch.json:

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

For Blazor developers, this is a game changer. You’re already running dotnet watch in the terminal — now your debugging stays in the same window too.

The browser also got independent zoom levels (finally), proper right-click context menus, and the zoom is remembered per website.

MCP server sandboxing

This one matters more than you might think. If you’re using MCP servers — maybe you’ve set up a custom one for your Azure resources or database queries — they’ve been running with the same permissions as your VS Code process. That means full access to your filesystem, network, everything.

Now you can sandbox them. In your mcp.json:

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

When a sandboxed server needs access to something it doesn’t have, VS Code prompts you to grant permission. Much better than the “hope nobody does anything weird” approach.

Note: Sandboxing is available on macOS and Linux for now. Windows support is coming — remote scenarios like WSL do work though.

Monorepo customizations discovery

If you’re working in a monorepo (and let’s be honest, many enterprise .NET solutions end up as one), this solves a real pain point.

Previously, if you opened a subfolder of your repo, VS Code wouldn’t find your copilot-instructions.md, AGENTS.md, or custom skills sitting at the repository root. Now with the chat.useCustomizationsInParentRepositories setting, it walks up to the .git root and discovers everything.

This means your team can share agent instructions, prompt files, and custom tools across all projects in a monorepo without everyone having to open the root folder.

/troubleshoot for agent debugging

Ever set up custom instructions or skills and wonder why they’re not being picked up? The new /troubleshoot skill reads agent debug logs and tells you what happened — which tools were used or skipped, why instructions didn’t load, and what’s causing slow responses.

Enable it with:

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

Then just type /troubleshoot why is my custom skill not loading? in chat.

You can also export and import these debug logs now, which is great for sharing with your team when something isn’t working as expected.

Image and binary file support

Agents can now read image files from disk and binary files natively. The binary files are presented in hexdump format, and image outputs (like screenshots from the integrated browser) show up in a carousel view.

For .NET developers, think: paste a screenshot of a UI bug into chat and have the agent understand what’s wrong, or have it analyze the output of a Blazor component rendering.

Automatic symbol references

Small quality-of-life improvement: when you copy a symbol name (a class, method, etc.) and paste it into chat, VS Code now automatically converts it to a #sym:Name reference. This gives the agent full context about that symbol without you having to manually add it.

If you want plain text instead, use Ctrl+Shift+V.

Plugins can now be enabled/disabled

Previously, disabling an MCP server or plugin meant uninstalling it. Now you can toggle them on and off — both globally and per-workspace. Right-click in the Extensions view or the Customizations view and you’re done.

Plugins from npm and pypi can also auto-update now, though they’ll ask for approval first since updates mean running new code on your machine.

Wrapping up

VS Code 1.112 is clearly pushing hard on the agent experience — more autonomy, better debugging, tighter security. For .NET developers, the integrated browser debugging and Copilot CLI improvements are the standout features.

If you haven’t tried running a full Copilot CLI session in Autopilot mode for a .NET project yet, this release is a good time to start. Just remember to set your permissions and let it cook.

Download VS Code 1.112 or update from within VS Code via Help > Check for Updates.

Visual Studio | The .NET Blog

Visual Studio 2026 April Update: Cloud Agent, Custom Agents, and Debugger Agent

Cloud agent: offload work to a remote Copilot session

Custom agents now travel with you

C++ Code Editing Tools go GA

Debugger Agent: fixes validated against real runtime behavior

IntelliSense priority fix

SDK-Style Support for Extension Projects in Visual Studio

What changes in the project file

Build time improvements

New projects vs existing

Agentic migration path

Worth noting

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

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

The setting

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

Quick recommendations

Wrapping up

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

Slot-based navigation

The Bookmark Manager

Organization with labels, colors, and folders

Export and share

Bookmarks that track code movement

Wrapping up

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

Custom Copilot agents in your repo

Agent skills: reusable instruction packs

find_symbol: language-aware navigation for agents

Profile tests with Copilot

Perf tips during live debugging

Fix NuGet vulnerabilities from Solution Explorer

Wrapping up

VS Code 1.112: What .NET Developers Should Actually Care About

Copilot CLI just got way more useful

Message steering and queueing

Permission levels

Preview changes before delegation

Debug web apps without leaving VS Code

MCP server sandboxing

Monorepo customizations discovery

/troubleshoot for agent debugging

Image and binary file support

Automatic symbol references

Plugins can now be enabled/disabled

Wrapping up