The Future of Visual Studio Extensions


With new improvements and additions such as GitHub Codespaces, Git Integrations, and IntelliCode Team Completions, Visual Studio has expanded to make development easier, more customizable, and accessible from any machine.  As we continue evolving Visual Studio, what about extensions?!  While still early in the design phase, we are creating a new extensibility model. This will make extensions more reliable, easier to write, and supported locally and in the cloud.


Crash Less, Code More!

Tired of seeing a feature or Visual Studio crash because of an extension?  Today’s in-proc extensions have minimal restrictions over how they can influence the IDE and other extensions. Thus, they are free to corrupt Visual Studio if the extension experiences an error or crash.  One of our biggest changes to the Visual Studio extension model is that we are making extensions out-of-proc. This will help ensure increased isolation between internal and external extension APIs, where a buggy extension can crash without causing other extensions or the entire IDE to crash, hang, or slow down along with it.


Easy to Write

Extensions are cool to use but can be difficult to write.  Inconsistent APIs, overwhelming architecture, and having to ask your teammates how to implement what should be a basic command are common feedback items from extension writers.  Discovering all these APIs can be challenging and once you do find them, it can be hard to know where or when to use them.  Luckily, designing the new out-of-proc extension model gives us the opportunity to completely redesign the Visual Studio extension APIs.  So, our goal is making writing extensions easier with more uniform, discoverable APIs and continually updated documentation.  Most importantly, the new model will preserve the power and extensive UI customizability options that today’s model provides.


Figure 1 shows the code required to initialize a command for Mads Kristensen’s Image Optimizer extension.  Figure 2 shows an example of what initializing the same command could look like using the new model.  Here, lines 31 and 32 in Figure 2 condenses and represents Figure 1’s AddCommand method calls. Figure 1’s DesignTimeEnvironment code (DTE) representing the IDE and its controlling methods is passed in via the VisualStudioExtensibility class in Figure 2.  Ideally, this simplifies the code and knowledge required to properly initialize the class.

Figure 1: Initialization code for Image Optimization extension using existing extension model
Figure 1: Initialization code for Image Optimization command using existing extension model


Figure 2: Example of possible Image Optimizer command initialization using new extension model


Extensions in the Cloud

Part of GitHub Codespaces’ appeal is the ability to have a customized dev environment accessible via the cloud across machines.  For many developers, a customized environment is incomplete without extensions.  The current model’s unrestricted access to the IDE and lack of asynchronous APIs don’t make it ideal for a seamless, crash-less, and responsive client/server experience for Codespaces. To round out our new extensibility model goals, we will make your essential extensions available both locally and remotely.

Figure 3: Image Optimizer extension running in a GitHub Codespace
Figure 3: Image Optimizer extension running in a GitHub Codespace


The Future

The road to completing the new extension model is a long one and today’s model will not be replaced overnight.  We are still in the conceptual phases of this new model, so sharing your experiences as either an extension user or an extension writer is very important.  To help us improve the extension experience, please share in the comments what extensions you can’t live without or complete this survey.


Stay tuned for future extension developments!


Comments are closed. Login to edit/delete your existing comments

  • Joseph Johnston

    CodesmithTools, JetBrains (Resharper and the Dotxx extensions).

    Out of proc will ease the burden of bit matching 32x vs 64x. Also, if there was an “Extension Ready” event we could load extensions asynchronously without stopping you from getting set up to work. No more “blah extension slowed you down click here to … ”

    I do like ReSharper but VS has many of the perks that drew me to it built in now. ReSharper is a model extension as it is truly seamless where studio ends and RS starts. I am still a paying customer. 🙂

    Additionally, it would be nice if you could see to it that it remains worth having the real visual studio over the freeware/shareware VS code. Some of us have been serious users of studio pro/enterprise since it came out and we DO feel neglected and as though we are wasting money at times. Just my MS Certified Partner 0.02¢ worth…

  • Michael Taylor

    Eliminating all the IServiceProvider stuff tied to COM objects that can only be called on UI threads would be a huge win for extensions. It is incredibly frustrating trying to get a service from some unknown thread just to have the service locator return nothing because you’re not on the correct thread. Or worse attempt to make a call on service and get a crash.

    outproc seems like a good call, and seems to be setting things up for an x64 version of VS??, but I’m really curious if we can truly get the same UI features that we have now without a noticeable slowdown. Today extensions can add quick actions and other features to the UI but they are inproc so the perf isn’t terrible, but it isn’t great either. There is a noticeable drop in perf when switching to outproc. I’ve noticed it quite a bit while debugging as more and more debugging/build tools are out of process. I’m also very curious about what happens in the UI when an outproc extension crashes or is killed. Does it auto-restart? Does the user get notified?

    Finally the startup time of VS is critical. Right now starting up VS on an SSD for me takes 30 seconds. This is with inproc extensions. The async loading of extensions helps but if they are now separate processes with probably other procs to talk with then it seems it’ll take even longer to actually be able to code. Being able to interact with the IDE is great and all but it is akin to Windows login being faster but you still cannot do anything until it finishes loading, which now takes longer.

    Personally I don’t care about support for Codespaces so I hope that extensions can opt into the “environments” they want to support. I can imagine some extensions are not useful in all cases. Even more important is that I probably don’t want all the extensions in all the environments so I’d be picking and choosing anyway.

  • Mike Perez

    I would rather see a 64-bit visual studio. It’s 2020 already! I know that’s not as easy as ‘flipping a switch’ (I’m sure it is a huge task) but the amount of times I have to close a hung visual studio because it ran out of memory and is endlessly trying to garbage collect is way too often. Moving out of proc seems like a good idea… but it seems like it’s working more around the actual issue.

  • Robert van der Hulst

    Although the idea of making writing extensions easier sounds very promising, I would also like to remind you that there are many 3rd parties out there that have to support not just the latest version of Visual Studio, but also some versions back.

    In my company (I am a member of the X# team) we are supporting VS2015, VS2017 and VS2019.
    If you create new APIs that are fundamentally different from the existing APIs, that will mean that we most likely have to invest a lot of time to support the new APIs and on the other hand we will have to maintain the old APIs as well, since we cannot force our users to switch to the latest version of VS. We are not looking forward to that.

    And another point that I would like to bring up is that not all extensions are alike.
    If you think of extensions, than please also see the C#, VB and F# language support as an extension.
    When these system can work in the new extension model then other languages can also work in this model.
    I know that there are at least a dozen, probably more, companies out there that (just like we are) add support for a custom language to Visual Studio at the level of a project system, language service, debugger, WPF editor, Windows Forms editor, Settings editor, resource editor etc.
    Getting this all to work was quite some work and I know that at least my company is not looking forward to do that all over again because you changed the extension model.


  • Ken Kasajian

    I think the problem with the Visual Studio Extension system is that often Microsoft creates extensions, such a running grunt, gulp, etc. files, that only work in Visual Studio, and MSBuild knows nothing about it.
    So then no on uses them because we all want our builds to work in the build system, not just Visual Studio.
    That would never be an issue with, say NodeJS. Nor *any other development environment*, because only Visual Studio has an entirely different build system that runs from Visual Studio than it does outside of it. For instance, open a solution and build it. Now that it’s build, build it again. Even with very large solutions, it takes a second or two and it doesn’t build anything because all the projects are already built. That’s how it’s supposed to work. Now, attempt to build the solution from the command prompt using MS-Build. It will take 2+ minutes to figure out that all the dependences are met and nothing needs to be done.
    Why the difference? Because there’s two different products that have different features sets that have to work on lock-step. What MSTest calls categories, Visual Studio calls Traits — it’s like they’re not even part of the same company.

    So using Extensions is a dangerous thing and should be avoided at all costs because people misuse it and we end up all sorts of extensions that shouldn’t be extensions.

    A true extension system would integrate in such a way that when you perform a build whether from Visual Studio or outside of it, the same thing happens.

    I wouldn’t even bother.

  • Mike Diack

    The ironic thing here – which I’ve already mentioned to the author of this blog, is that at this very moment, the Resharper team at JetBrains are trying to move Resharper out of process for performance reasons and to avoid problems of hitting the 32 bit addressing limit of the hosting VS IDE process. Would surely hope that both teams are liaising. Apparently JetBrains have been working off and on at it for at least 3 years!