Updates to synchronous autoload of extensions in Visual Studio 2019

Mads Kristensen

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.

Mads Kristensen
Mads Kristensen

Senior Program Manager, Visual Studio Extensibility

Follow Mads   

21 comments

Comments are closed.

  • Avatar
    Richard Pastrick

    This seems like the perfect place for a user controlled white list of extensions allowed to synch load instead of a blanket, everyone can synch load.

    • Mads Kristensen
      Mads Kristensen

      It would be, but the ability to load synchronous extension is the exception to the rule. We really don’t recommend you ever do that as the post explains. The scenarios is primarily intended for enterprises who has no other workaround. Even if you allow synchronous autoloaded extensions, you will still get a yellow notification when you install a new extension that synchronous autoloads, so you can decise if it’s worth keeping it enabled/installed or not.

  • Avatar
    Stanton, Andrew

    What good does having a fast solution load do if you are blocking the tools that correct the productivity problems within visual studio? Since you didnt know the answer to that, its “None”.Solution loading is really not that slow, and definitely not slow compared to the time I have to spend in the awful VS Merge tool. Make an extension that replaces that so I dont have to keep replacing it manually.EDIT: And why did you make VS now freeze for several seconds on startup before showing this gold bar notice? It wasnt doing this before you deprecated the API’s. Smells like crippleware to back ones argument to me.

    EDIT 2:  Dont include breaking changes in a minor release. Nobody is expecting to have productivity stopped by a quick lunchtime VS update.

    EDIT3: (Oct 2019) This message complains about an extension that is DISABLED and thus not loaded. Please Fix

  • Avatar
    André Ziegler

    as I commented in your last blog post about extensions, several extension authors have issue to keep compatibility with VS2017 when they switch to AsyncPackage because Microsoft.VisualStudio.Shell.15.0 in Version 16.0.0.0 is not found. What do they have to do to support both? CreateInstance failed for package [FooPackage]Source: ‘mscorlib’ Description: Die Datei oder Assembly “Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden. System.IO.FileNotFoundException: Die Datei oder Assembly “Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden. File name: ‘Microsoft.VisualStudio.Shell.15.0, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a How long is IAsyncLoadablePackageInitialize supported? Will such packages also be unloaded in future VS2019 versions? Make a video and show all steps to make it async while keep 2017 compatibility.

  • Avatar
    Dave Bacher

    Is this also why Visual Studio no longer picks a plug-in at random (including, in some cases, built-in Visual Studio capabilities) when there is a crappy network connection?
    When connection was bad – say a LTE Hotspot with 1 bar to the tower – Visual Studio 2017 would just pick a plug-in at random, and report “this plug-in is causing the IDE to load slowly.”  Sometimes, it would be built in plug-ins like the Solution Explorer.  I have not seen it one time in Visual Studio 2019 – and so I suspect it’s fixed, probably because of this?

  • Matthieu Penant
    Matthieu Penant
  • Avatar
    Matthew Fabrizi

    Please continue to support the ability to opt-in to enable synchronously loaded extensions. The developers in my group use an extension we authored that does many things to tailor the build environment, but, most importantly, hooks the OnBuildBegin build event to update header files and resources that are dependencies for the build. Builds may fail or use stale data without this, so it’s mandatory that this extension be loaded before a build begins. We experimented with switching the extension to support asynchronous loading, but it’s fairly easy for someone to kick off a build before the extension loads. We don’t mind trading a slightly slower Visual Studio loading experience to know that the environment is actually configured properly, so we’re definitely going to use the ability to opt-in to synchronously load our extension. It sounds like Microsoft has gotten enough push back that it will likely continue to support this ability, but I’d like to add some more weight to the scale. Asynchronous loading is not always a great thing. We require a deterministic experience. It doesn’t help us that Visual Studio loads quickly if the environment is not actually fully-configured until some indeterminate time later.

    • Avatar
      Matthew Fabrizi

      The ability to enable synchronously loaded extensions is necessary for our use case, but I also want to point out that we continue to develop and enhance our extension. If possible, we’d like to be able to build our extension in Visual Studio 2019 (and beyond). As it stands, we need to retain Visual Studio 2017 in order to recompile our Package-derived extension because Visual Studio 2019 only supports AsyncPackage. Also, from our perspective Visual Studio 2019 first has to fail to load our development environment, the developer enables synchronously loaded extensions (via prompt or in the Tools | Options dialog), and then restarts the IDE. What if the manifest could somehow indicate that the extension requires synchronous loading support? Perhaps that makes it easier for Visual Studio to prompt for synchronous loading support *prior* to rejecting our extension. This is not as important, but it would be nice if the IDE didn’t “fail” the first time.

  • Avatar
    Liviu Duma

    Hi,
    I created an extension as in the exemple provided (basically I did a fork of AsyncPackageMigration ), but in Visual Studio 2019, at least, I still get that Async Package Migration was not loaded because it uses deprecated syncronous autoload APIs.
    Can someone please provide some help on this, because it seems that the exemple does not work.

    Thank you

    • Avatar
      Liviu Duma

      Hi,
      I’ll reply here to my own question, may be it will be useful for someone else: when you do the switch from Package to AsyncPackage, remember to update the version number of the extension too, because otherwise, in my case at least, Visual Studio still “remembers” that that extension was loaded Synchronous and it kept showing that the extension is deprecated.
      Cheers,
      Liviu

  • Jez
    Jez

    I find this change extremely annoying, and whilst Microsoft may wish to make an informational comment on synchronous extension performance, I don’t think they should ever officially deprecate these kinds of extensions.  As many have commented, there are lots of useful extensions out there that load this way.  The one that was key for me was the custom document well in the Productivity Power Tools, which has not been ported over to loading asynchronously, meaning I either have to put up with the default (inferor in several ways) tab well, or hack the VSIX for the old document well to get it to work.
    Not good.  Not good at all.  Stop trying to make these decisions for us, MS.  Give a small warning but don’t say “we’re gonna remove this functionality completely one day” like some sword of Damocles.