If you’ve been following this blog, you know that in Visual Studio “15” we’ve been focused on making our developer tools easier to install, increasing performance, and enhancing developer productivity. We’ve been doing the same for extensions, and it’s time to talk a bit more about the implications of these changes both on extension authors and on customers who are using extensions.

A quick summary of the changes we’re making:

• We’ve added a performance monitoring system for extensions. Customers will now see a gold notification bar when an extension is slowing load time or typing speed;
• We now batch extension updates and installs to make it easier to install or update multiple extensions;
• We’ve made it possible for extensions to detect and install dependent components, now that the default installation footprint of Visual Studio is much smaller;
• We’ve made several performance improvements that have an impact on extension authors, such as lightweight solution load and NGEN support for extensions;
• Lastly, we’ve updated the Visual Studio marketplace to make it easier to find and install extensions;

The rest of the post goes into more detail on each of these areas.

If you’re an extension author, you’ll want to read this post carefully, since we’re asking you to do some work in this release to support the performance and installation work we’re making to Visual Studio. There is some inevitable friction here, and so we want to give you a heads-up so that you can make the appropriate changes to your extension before we go live.

Performance

One of the top extensibility requests in UserVoice is for tools that let extension users identify slow extensions and disable them if necessary. We designed the extensibility model in Visual Studio to offer great power – authors largely have access to the same APIs that we use internally – so it’s important that extensions do not degrade overall product performance.

In Visual Studio “15”, we have focused on addressing three specific performance bottlenecks in particular: (i) Visual Studio startup performance; (ii) solution load performance; (iii) overall responsiveness. And in addition to improving our own performance, we’re now also adding features to help you measure and manage extension performance in these areas.

If we detect a slow-performing extension that falls into one of these categories, we will display a message that identifies the extension and gives the user the opportunity to disable it. Here’s an example with a malicious extension that sleeps for six seconds during initialization:

You can see the performance of extensions on your system at any time by selecting the Help / Manage Visual Studio Performance menu item.

We trigger this notification by measuring the total initialization time spent by the extension on the main thread. If it exceeds a lower time threshold, we will warn users that the extension is loading slowly; if it exceeds a second, still higher time threshold, we will offer to disable the extension for the user.

We use the same dialog to also track extensions that introduce delays to typing responsiveness. Studies have shown that input latency greatly impacts the perception of an application’s performance. So, Visual Studio now measures the duration of calls within extensions to extension command filters and editor event handlers that are triggered by typing characters, and if those calls regularly take longer than a predefined threshold, we display an infobar to warn users of the impact of that extension on typing responsiveness:

If you’re an extension author, we recommend these best practices to ensure your extension performs well in Visual Studio:

1. Use rule-based contexts to specify precise conditions when your extension should be loaded. For example, you can ensure that an extension is only loaded when a C# or Visual Basic project is active, rather than at Visual Studio startup.
2. Use the AsyncPackage support in Visual Studio 2015 and above to allow packages to be loaded on a background thread.
3. Review your extension’s command filters and editor event handlers (such as ITextBuffer.Changed) and perform any operations longer than 50ms asynchronously;
4. Minimize work performed during package initialization, deferring it instead to occur on invocation of a user action.

Batched Extension Installations

Another common feature request from Visual Studio 2015 was to make it easier to install, update and remove multiple Visual Studio extensions at once. Visual Studio “15” now lets you batch up extension change operations to occur at once.

Here’s a screenshot:

Size

With the new Visual Studio installer, we have refactored Visual Studio to be more modular, installing just the features you need for the work you’re doing. The smallest configuration of Visual Studio installs in just a couple of minutes on typical machines, and the increasing number of Visual Studio developers who are using it for new platforms and languages like Python and R no longer need to install support for things like C#, MSBuild and ASP.NET to get a great Visual Studio working environment.

We’ve therefore created a way for extension authors to express their Visual Studio component dependencies by extending the VSIX manifest. The model is designed so that if dependencies are missing, the extension installer can acquire and install the missing components automatically. With this approach, for example, an extension can hint to the installer that it requires the managed language debugger to be available for the extension to run successfully.

We’re updating the extensibility tools to automatically emit these changes for new projects. By default, we set a dependency on just the Core Editor, but you can add additional components by selecting them from the Prerequisites tab. Here’s a screenshot:

The next public build of Visual Studio “15” will contain the updated manifest designer, and we’re planning to ship an update to the tools in Visual Studio 2015 to support the new manifest format before we complete Visual Studio “15”.

New Extension Capabilities

We’re taking advantage of the changes to the standard VSIX extension format to add some powerful new capabilities for extension authors.

• Extension assemblies can now be compiled into native images (through NGEN) at install time, for added performance. You can specify NGEN options from the Properties toolwindow:

• Extensions may now install files in certain locations outside of the extensions folder. This enables new scenarios like MSBuild tasks to be installed from a VSIX folder.

One caveat: these capabilities are only available for “all user” extensions because they require elevation. We hope to encourage extension authors who have until now been forced to wrap their VSIX in an MSI to accomplish these needs to be able to transition to a pure VSIX, enabling better manageability, roaming and auto-update capabilities for users of their extensions.

Lightweight Solution Load

In Visual Studio “15”, solutions will load faster due to support for lightweight solution load. When lightweight solution load is enabled, Visual Studio will delay fully loading projects until you start working on them. Visual Studio will still preserve common functionality, such as allowing you to navigate through your codebase, edit code, and build projects without fully loading projects. We’ve seen this speed up solution load by a factor of two or more.

This feature is still “experimental”, so to try out this feature in Visual Studio “15”, you’ll need to manually enable the lightweight solution load checkbox in Tools / Options / Projects and Solutions.

If you’re an extension author, lightweight solution load may impact your extension if you depend on a project to be fully loaded. Our team is putting together steps and guidance on how extensions can know when projects are not yet fully loaded, and how to respond accordingly. We will share this guidance as soon as possible.

Detecting Installations

Some tools need to get more specific information about a Visual Studio installation, for example an external utility that needs the location of the C++ compiler toolset. Along with the changes to Visual Studio to reduce system impact, we’ve added some new setup configuration APIs to make it easier to discover instances of Visual Studio “15”. Heath Stewart’s blog includes more detail about these APIs and samples for managed and unmanaged code.

Marketplace

One last significant change: we’re transitioning to the Visual Studio Marketplace as a place for discovering and installing extensions, again in response to your feedback. The marketplace is a modern website that supports extensions for our developer tools family, including Visual Studio itself, Visual Studio Code and Visual Studio Team Services.

In the next months, we’ll begin the process of retiring the old Visual Studio Gallery. You don’t have any work to do if you’re an extension author – we’ll migrate all the data across automatically. We are excited by some of the new features we’ll be able to offer extension authors and users alike once we are live on the new site.

More Information

If you’re building an extension for Visual Studio “15”, we’re glad to hear from you. In particular, the editor and extensibility engineering teams hang out on our Gitter team room along with many other extension authors. You can also submit or vote on feature requests in the extensibility area of our UserVoice site – we’re listening!

Tim Sneath, Principal Lead Program Manager, Visual Studio Tim leads a team focused on Visual Studio acquisition and extensibility. His mission is to see developers create stunning applications built on the Microsoft platform, and to persuade his mother that her computer is not an enemy. Amongst other strange obsessions, Tim collects vintage releases of Windows, and has a near-complete set of shrink-wrapped copies that date back to the late 80s.