Updates to synchronous autoload of extensions in Visual Studio 2019

Mads

Since announcing that Visual Studio 2019 v16.1 will block any extension from synchronously autoloading, we’ve seen a tremendous effort of both 1st and 3rd-party extensions to implement async background load. It’s been truly amazing to see the community of extension authors stepping up to the task. Many even did it long before we announced Visual Studio 2019.

The result is faster startup and solution load times for Visual Studio, as well as fewer UI delays cause by blocking operations on the main thread. So, a big THANK YOU to all extension authors for all the hard work to make this happen.

Control the behavior

By default, Visual Studio 2019 v16.1 blocks any synchronously autoloaded package from any extension and shows a notification to alert the user about it.

Yellow bar notification

What’s new is that the individual user can now control how they would like the extension to load. The reason for this change is two-fold.

First, most extensions now support async background loading, which improves startup and solution load performance across the board. Second, there exist a class of extensions developed and used internally in companies around the world that for various reasons cannot support async background load. It’s usually because they no longer have the source code or the person who originally built the extension is no longer working at the company.

To stop blocking synchronously autoloaded extensions, you can either click the Allow synchronous autoload on the yellow notification bar or check a new checkbox in the options dialog.

Extensions options

It’s important to stress that we really don’t recommend to anyone that they allow synchronous autoload, but we recognize the need to be able to unblock users and teams to do their job. Even when we know it leads to degraded performance of Visual Studio.

Group policy

To set this option for all team members, the IT admin can now set a registry key through Group Policy. When the Group Policy is set, it takes precedence over the individual user’s ability to change the option themselves, and the checkbox is greyed out and disabled.

Marketplace updates

Extension authors must still use AsyncPackage and enable background load. An update to the Marketplace shows errors when uploading any extension supporting Visual Studio 2019 that uses synchronous autoload. This update is in place since no extension can make assumptions about the users allowing synchronously autoloaded extensions.

Simply put

Here’s a bullet list to sum it up:

  • Marketplace requires autoload to be async and in the background
  • Users and IT admins can opt out of the blocking behavior (not recommended)
  • Autoloading extension should always happen asynchronously in the background

Again, thank you so much for your efforts to make Visual Studio perform better to the benefit of all users. We appreciate the hard work and understand that on many cases it took a considerable amount of work to make this happen. You have our sincerest respect and admiration.

21 comments

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

  • Hugo Ribeiro

    Hi. ModelingPackage (from the DSL-Tools in the Modeling SDK) derives from Package and it hasn’t changed for years now…
    We use it extensively to customize the IDE for our multiple development teams. We have in fact created our own modeling framework to assist in the development of our business apps (ERP). So, it is very important for us that these DSLs load when Visual Studio loads.
    The option is all well but those warnings are simply very annoying.
    My questions is (are):
    – Will ModelingPackage get an update to support AsyncPackage?
    – When are you really planning to discontinue the Modeling SDK (since it has no new features for so many years now)?

    • Mads KristensenMicrosoft employee

      You’ll have to manually change the generated code to use AsyncPackage from the Modelling SDK. We have no plans to discontinue the Modelling SDK