The Future of Visual Studio Extensions

Leslie Richardson

Leslie

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

 

"<yoastmark
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!

29 comments

Leave a comment

  • Avatar
    Patrick Hintermayer

    For me, my top 3 extensions are:
    1. Add New File
    2. CodeMaid
    3. Viasfora

    Other nice to have extensions are:
    – Visual Studio Spell Checker (VS2017 and Later)
    – File Icons
    – JavaScript Snippet Pack
    – Image Optimizer
    – ResXManager

    In Visual Studio Code there are many cool features which I’d like to see in Visual Studio, like extensions being synchronised with the account or installing / uninstalling extensions without closing and restarting Visual Studio.

  • Avatar
    MgSam

    If you’re rewriting the extension API, please please please make Visualizers part of the extension API this time around. The only reason we don’t have a myriad of graphical and tabular visualizers for data in .NET debugging is because Visual Studio has no support for visualizers as extensions and doing so requires extensive and brittle workarounds.

    I’d love to bring my DataGrid Visualizer back but I won’t invest more time in it unless I know it’s using a supported API that won’t break with the very next release of Visual Studio.

    • Avatar
      Evgeniy Alexandrov

      “How essential to your development environment are the extensions you use in Visual Studio?” and “Would you continue to use Visual Studio if your essential extensions were not supported?” is probably the best spot to highlight them. If this change kills ReSharper in Visual Studio, it will force me to abandon Visual Studio.

      • Avatar
        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!

  • Patrick Smacchia
    Patrick Smacchia

    Many extensions add extra windows and extra menus to VS. How do you plan to handle that out-of-proc? Will you provide an IPC channel API and some sort of memory shared for windows bitmaps?

    Looks like you will unify VS, VSCode, VS for Mac, CodeSpaces… and in this .NET 5 unification era it makes sense.
    Do you plan to migrate to a cross platform UI framework that supports desktop + web? Will it be Maui?

    • Leslie Richardson
      Leslie RichardsonMicrosoft employee

      Hi Patrick,

      For UI extensibility, we are still exploring options. We fully understand the need to create complex extensions that offer windows, menus, and other rich UI and it’s not our goal to take that away. Changing the extensibility model for VS is a tall order and we want to make sure we do things right. We are focusing on simple extensions first that do not need UI extensibility, while continuing to explore various frameworks for UI. We will definitely engage the community on that topic when the time comes, so please stay tuned.

  • Avatar
    Marius Bancila

    The biggest problem I had over the years trying to write several extensions was not the complexity of the API but its lack of proper documentation. It’s been really difficult to find resources that teaches someone how to write an VS extension from scratch and going from the basics to the advanced. You can change the API model any way you want. If documentation is not available it won’t be easier.

  • Avatar
    TSX

    Could be great if extensions could be part of project. In this model, project may contain some UI stuff, that is used by VS for design and debug. Similar to Roslyn analyzers. With nuget widespread usage, distributing ‘extensions’ will be simple.

  • Ken Domino
    Ken Domino

    Making the extension out-of-process is a good idea. For example, the json-rpc transport used for the LSP protocol is a good way to go. However, please don’t add another cargo cult system just for VSIDE and not consider VSCode, or other IDEs. Please work with VSCode and other IDEs to come up with a simple, basic unified model of the client-side IDE initially, open-source it, and allow all to contribute to it like LSP. It doesn’t have to be all-encompassing. You, MS, can then start implementing this model in the existing VSIDE, so we extension writers can then focus on the extension. Yes, there’s going to be a lot of really stupid people trying to add really stupid features, but put a standards body together, create a plan, and make sure we’re going to get there.

  • Blake Niemyjski
    Blake Niemyjski

    How will this be supported and what all will this support? I wrote the CodeSmith Generator add-on and we are currently blocked on supporting VS2019 due to we have a nuget package reference to roslyn and the bin folder and assemblies isn’t included in the generated VSIX of which we cannot even get support or a hot fix for this issue leaves me wanting to see what the support for this new model is going to be…… We have tool windows, property grid integration, menu items, msbuild / source control integrations, our own design surface, find and replace support, etc… How will all of this be supported in the new model? Do you see it being something like https://github.com/niemyjski/VSXtra

    This isn’t the first nor the last rewrite I’ve seen of the VS Integrations… Us ISV’s also have to support previous versions, which we always get the feeling the previous version is dead once the new shiny thing is released (especially when you need support of the old thing and you are asked does it work with the new).