SDK-Style Support for Extension Projects


Starting in Visual Studio 18.5, you can create and build Visual Studio extensions (VSIX) using an officially supported SDK-style project. This brings VSIX projects into the modern build and deployment pipeline, improving incremental build performance and making the build → deploy → debug workflow more reliable. Install the Visual Studio extension development workload to get the templates and tooling and try it out for yourself!

Note: Extensions written using the modern VisualStudio.Extensibility framework already supports SDK-style projects today. This update extends the same SDK-style experience to VSSDK-based Visual Studio extensions.

 What We Are Adding:

  • Official SDK-style support for projects that produce VSSDK-based extensions.
  • Build time reductions of up to 75%! We’ve added end-to-end incremental build support including Fast Up To Date Check and up to date deployment logic. Through internal adoption, we see a reduction of up to 75% in build time in large solutions for small changes or changes confined to a single sub project.
  • Updated in-box templates: SDK-style by default, with the familiar project items (tool windows, classifiers, commands, etc.).

Project Usage

Creating a project is done the same way you are used to, using the “VSIX Project” or “Empty VSIX Project” template:

new vsix project template image

This will yield a much more compact csproj than before: only 20 lines:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
    <Nullable>enable</Nullable>
    <LangVersion>14</LangVersion>

    <!-- VSIX settings -->
    <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>

Does it impact my extension?

  • If you create a new extension, you will automatically get full SDK-Style support.
  • Your existing MPF style extension will continue to work should you choose not to migrate. This update adds an official SDK-style option; it doesn’t force a conversion.
  • You can update your project to an SDK-style project file to take advantage of these features.
  • Vsixmanifest files included in SDK-style projects now open by default in the XML editor. The old designer is still available through the ‘Open With’ menu.

Migration In Brief

  • When available, you can do this in the project configuration:
    configuration manager image
  • <VSSDKBuildToolsAutoSetup>true</VSSDKBuildToolsAutoSetup> will setup most sensible defaults for you and reduce the size of your csproj. This will setup options like CreateVsixContainer as true, and the legacy DeployExtension to false.
  • <VsixDeployOnDebug>true</VsixDeployOnDebug> Should be added to your csproj if you will add it to other solution files to ensure the deploy checkbox is set automatically.

Agentic conversion

We’re experimenting with ways of making this as easy as possible for you. To that end, we’ve added an agent skill to the vs-agent-plugins repository you can use in conjunction with the Modernize agent. Let us know whether this workflow is helpful, or if you have a different agentic workflow in mind for extension development.

modernize agent image

Reference projects

Here are a few extensions that are already converted, so you can use them as references.

We want to hear from you!

Please send us feedback and issues you encounter in Developer Community. Thank you, and happy extending!

Bookmark Studio: evolving bookmarks in Visual Studio


Bookmarks in Visual Studio have always been a simple, reliable feature. Many developers use them regularly, and over the years we’ve heard consistent feedback from those users. Bookmarks were useful, but there were a few core gaps that kept them from being as effective and relevant as they could be.

Navigation was one of the biggest pain points. You could move between bookmarks, but there was no easy way to jump directly to a specific bookmark using the keyboard. That made bookmarks harder to rely on once you had more than a few. Another common request was sharing. Bookmarks worked well for personal, local navigation, but there was no good way to share them with teammates or reuse them across repos, branches, or pull requests.

That feedback is what led to Bookmark Studio, a new experimental Visual Studio extension that builds on the existing bookmark experience by filling in those missing pieces, without changing how bookmarks fundamentally work.

Faster, more intentional navigation

One of the core additions in Bookmark Studio is slot‑based navigation.

Bookmarks can be assigned to slots 1 through 9 and jumped to directly using simple keyboard shortcuts like Alt+Shift+1 through Alt+Shift+9. This makes bookmarks feel more deliberate and easier to rely on when you want fast access to a handful of important locations.

Toolbar

New bookmarks are automatically assigned the next available slot when possible, so fast navigation often works without any extra setup. Bookmark Studio also integrates with Visual Studio’s existing bookmark commands, which means your current shortcuts and muscle memory continue to work as expected.

A single place to work with bookmarks

Bookmark Studio also adds a dedicated Bookmark Manager tool window.

Tool window

The manager shows all bookmarks in one place and makes it easy to browse, search, and navigate between them. You can filter by name, file, location, color, or slot, and jump directly to a bookmark with a double‑click or keyboard navigation. It’s designed to make bookmarks easier to revisit, especially when switching context or coming back to code later.

Optional structure, when you need it

Another piece of feedback we heard was the need for just a bit more organization.

With Bookmark Studio, bookmarks can have labels, colors, and folders. None of this is required, and you can keep using bookmarks exactly as you do today. But when you’re debugging, refactoring, reviewing code, or exploring unfamiliar areas of a codebase, that extra context can make bookmarks more useful and easier to reason about.

Glyphs

All bookmark metadata is stored per solution, so it stays with your work across sessions.

Bookmarks you can share and reuse

Bookmarks are often most valuable when they capture intent, not just location.

Bookmark Studio makes it easy to export bookmarks as plain text, Markdown, or CSV. That means you can include bookmarks in pull requests, share investigation paths with teammates, or move useful bookmark sets between repos. Instead of being a purely personal tool, bookmarks can become a lightweight way to communicate context and decisions.

Bookmarks that stay put as code changes

Bookmark Studio tracks bookmarks as text moves during editing, so they stay attached to the relevant code instead of drifting to the wrong line. This makes bookmarks more dependable during active development, especially when files are changing frequently.

Drag and drop of glyph

A focused improvement, not a reinvention

Bookmark Studio doesn’t try to replace tasks, TODO comments, or issue tracking. It doesn’t introduce a new workflow you have to learn. Instead, it fills in the gaps that many bookmark users have pointed out over time, making bookmarks easier to navigate, easier to share, and more useful as part of everyday development.

If you already use bookmarks in Visual Studio, Bookmark Studio should feel familiar within minutes. And if you’ve ever wished bookmarks could do just a little more, this extension is worth a look.

You can download Bookmark Studio today from the Visual Studio Marketplace. As always, feedback and pull requests are welcome on the GitHub repo.

Performance improvements to MEF-based editor productivity extensions


If you use editor productivity extensions for Visual Studio 2026, there’s good news—they can now load faster! Extension developers with existing MEF-based editor productivity extensions should read this blog to learn about recent changes and how they might be affected. 

We introduced VisualStudio.Extensibility to simplify the creation of Visual Studio extensions for developers. Previously, handling threads in VSSDK-based extensions was often difficult, requiring knowledge of thread affinity and even the ins and outs of COM just to avoid freezing Visual Studio. The new extensibility model abstracts these technical details away seamlessly. 

Despite this advancement, we recognize most Visual Studio extensions still use VSSDK, so we’re striving to make targeted improvements there as well – especially regarding performance. For Visual Studio 2026, we’ve added the ability to load MEF-based editor extensions on a background thread, which significantly speeds up startup times for users. A major highlight of Visual Studio 2026 is its improved performance, and the proposed change we’re making to MEF is just one of many enhancements planned to make it even faster. We hope you’ll be pleased with the results. 

What changed? 

Visual Studio editor components use the Managed Extensibility Framework (MEF), which requires that objects be constructed in a free-threaded manner. Despite official MEF guidelines, we’ve often loaded components on the UI thread, resulting in many extensions relying on this behavior and limiting our ability to enhance startup performance. 

With Visual Studio 2026, we’re shifting to a free-threaded model, loading MEF components on background threads. This means extensions with UI thread dependencies might fail to load. We’ve been rigorously testing this approach in recent Visual Studio 2022 updates, and we are aware that some extensions that expect to load on the UI thread will fail to load with this optimization. To support extension developers through this transition, we’ve provided a setting and an analyzer that allows you to experiment with background loading and detect if your extension could be impacted by this change before we push it out more broadly. This initiative reflects our commitment to reducing disruptive changes and help extenders adapt when updates are necessary for the overall improvement of the product. 

Does it impact my extension? 

To help extension developers better detect if this change impacts you, we created an analyzer to identify potential issues. We hope that this will give you the opportunity to bring your extension in compliance with MEF rules, so that your extension can also get a startup performance boost like the rest of Visual Studio 2026. 

The example below shows the analyzer running and reporting access to the Microsoft.VisualStudio.Shell.ThreadHelper  and DTE2.StatusBar require UI thread. 

Picture1 image 

 To use the analyzer, add a reference to the latest version of the Microsoft.VisualStudio.SDK.Analyzers package: 

<PackageReference Include="Microsoft.VisualStudio.SDK.Analyzers" Version="17.7.98" PrivateAssets="all" />

To validate your extension can adapt to this change, enable the Preview Feature flag “Initialize editor parts asynchronously during solution load”. 

Picture2 image

When debugging, you may set a breakpoint in MEF part constructors and evaluate System.Threading.Thread.CurrentThread.ManagedThreadId. If it’s different than 1, then your code executes on the background thread.  

Picture3 image

Call to action 

Loading MEF parts on a background thread is essential for improving Visual Studio’s performance, and we have gradually enabled this change in Visual Studio 2026. We recognize that code changes can be inconvenient, so we’ve made it straightforward to spot and resolve any issues. To see examples of removing UI thread affinity, please see our documentation or a sample PR on how we made this change ourselves.  

We want to hear from you! 

Thank you for sharing your issues and suggestions with us, and we hope you’ll keep providing feedback about what you like and what we can improve in Visual Studio. For those new and experienced to extending Visual Studio, we invite you to visit our documentation to learn more, or watch the video series on Visual Studio Toolbox where Visual Studio engineers take you through how to build extensions using our samples on GitHub. Feel free to share feedback with us viaDeveloper Community: report any bugs or issues viareport a problemandshare your suggestionsfor new features or improvements to existing ones. If you want a closer engagement with other partners in the ecosystem, please visit our GitHub repo to report issues as well. 

Stay connected with the Visual Studio team by following us on YouTubeTwitterLinkedInTwitch and on Microsoft Learn