New features for extension authors in Visual Studio 2019 version 16.1

Mads Kristensen

Earlier this week, we released Visual Studio 2019 version 16.1 Preview 1 (see release notes). It’s the first preview of the first update to Visual Studio 2019. If you’re not already set up to get preview releases, then please do that now. The preview channel installs side-by-side with the release channel and they don’t interfere with each other. I highly recommend all extension authors install the preview.

Got the 16.1 preview installed now then? That’s great. Here are some features in it you might find interesting.

Shared Project support

There are several reasons why extension authors sometimes must split an extension into multiple projects to support the various versions of Visual Studio. If you’re using an API that did not exist for an earlier version of Visual Studio or if there are breaking changes between the versions you want to support, now there’s a simple easier to split your extension.

With Visual Studio 2019 version 16.1 Preview 1, we’ve added support for referencing Shared Projects from VSIX projects in the same solution.

You can place common code in a separate Shared Project that compiles directly into the VSIX projects at build time. The only code that then exists in the VSIX projects themselves, is code that is specific to the Visual Studio version it supports. The result is two separate VSIXs that target their own specific Visual Studio version range and share most of the code from the Shared Project. Checkout the code for the Extension Manager extension that does exactly this.

No more need for .resx file

When adding commands, menus etc. using a VSCT file, you must specify a .resx file marked with the MergeWithCTO MSBuild property. The templates in Visual Studio takes care of adding that file and it also adds a .ico file referenced by the .resx file. However, the need for a .resx is an implementation detail and most extensions don’t need to use it.

In an effort to make VSIX project simpler, the requirement for the .resx/.ico files have been removed when using the latest Microsoft.VSSDK.BuildTools NuGet package version 16.0 or newer.

Behind the scenes, the NuGet package provides an empty .resx to compile with the MergeWithCTO property unless you registered your own in the project.

Per-monitor awareness

Additional per-monitor awareness support is being enabled in 16.1 with .NET Framework 4.8 installed. Windows Forms UI now better handle DPI scaling across monitors. However, this may cause UI issues in your extension after installing .NET Framework 4.8.

When using Windows Forms in an extension, you can match the Visual Studio 2017 scaling behaviors by wrapping your form or control creation in a DpiAwareness.EnterDpiScope call.

using (DpiAwareness.EnterDpiScope(DpiAwarenessContext.SystemAware))
using (var form = new MyForm())

All you need is to add a reference to the Microsoft.VisualStudio.DpiAwareness NuGet package. Use this package in extensions targeting earlier versions of Visual Studio too but be aware that it will only take effect when running in 16.1 and newer. So, it is safe to use in extensions spanning multiple versions of Visual Studio.

To make it easier to simulate multiple monitors running with different DPI scaling, an engineer from the Visual Studio IDE team built a handy little tool and put it on GitHub. The team used this tool while they were adding support for per-monitor awareness, so you may find it helpful too.

Read more about how to deal with per-monitor awareness for extenders.

Synchronous auto-load disabled

18 months ago, we sent an email to extension partners announcing the deprecation of synchronous auto-loading of extension packages. A year ago, we followed up with a blog post with more details that outlined that synchronously auto-loaded package would be unsupported in a future version of Visual Studio. That version is 16.1.

There are great samples on how to migrate to AsyncPackage with background load enabled, and most extensions today have already made the transition. If you haven’t already, now is a good time to do that before 16.1 goes out of preview.

New SDK meta package

The meta package Microsoft.VisualStudio.SDK is a single NuGet package that references all the various Visual Studio packages that make up the SDK. The cool thing about the meta package is that you have access to all the interfaces and services. In addition, you also avoid issues with mismatched package versions.

When we released Visual Studio 2019 (16.0), the VSIX Project template referenced the 15.9 version of the SDK meta package. That was because the 16.0 version was still under development. All the individual packages had to be published to NuGet before we could take dependency on them from the meta package.

The good news is that now we finally have the 16.0 version ready. You should use it if the lowest version of Visual Studio if your extension supports 16.0. and you can read more about extension versioning here.


Discussion is closed. Login to edit/delete existing comments.

  • t r 0

    Need native C++ sample for AsyncPackage extension!

  • Stan Wijckmans 0

    No no no, you simply cannot disable synchronous extension before custom document well is implemented! This very popular extension cannot work without this and as temporary workaround we edit the vsix to get it installed. It’s being worked on to get this feature inside VS itself but until that’s done you CANNOT kill the only way to get probably the most used extension working.

  • Mike Ward 0

    So just to be clear, extensions that don’t implement AsyncPackage will stop working in 16.1?

    • Mads KristensenMicrosoft employee 0

      No, only the ones that auto-loads. Typically that is done when using the [ProvideAutoload] attribute on the package class. 

    • Yann Duran 0

      This excellent extension called Extensions in Main Menu will bring back top level menus for the extensions that you decide should be there.This is how Microsoft should have introduced their unneccesary change! Everyone can now be happy, those who need the old behavior that was in VS 2017 (as well as every prior version), as well as those who like the new behavior that was introduced in VS 2019.

  • Carlos Quintero 0

    Hi Mads,
    Could your team create an official standalone NuGet package for the VsWebSite.Interop.dll assembly used in automation/extensibility for web sites (introduced in VS 2005) that EnvDTE80 doesn’t cover? (See I am not sure if it’s worth to include it in the meta package but certainly it would be great as standalone NuGet package. I am trying to migrate from TFVC (where I have referenced VS DLLs in source control) to Git (which doesn’t like very much DLLs in source control) and therefore I am switching to NuGet packages, and this one is missing.
    Thanks in advance

  • Marat Abdullaev 0

    Analysis Services extension keeps crashing. Resetting settings has helped as a workaround. But whole program crashes once you try to add a data source! 

  • Matthieu Penant 0

    Are there any plans to make PackageReferences available for VS.Extension projects?

    • Mads KristensenMicrosoft employee 0

      The support for PackageReference in a VSIX Project was introduced in Visual Studio 2017 v15.8. It’s the default in Visual Studio 2019

      • Wil Wilder Apaza Bustamante 0

        This comment has been deleted.

  • André Ziegler 0

    Several extension fail to run in VS2017 after authors updated them to AsyncPackage:

    CreateInstance failed for package [FooPackage]Source: ‘mscorlib’ Description: Die Datei oder Assembly “Microsoft.VisualStudio.Shell.15.0, Version=, 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=, 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=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’at

    So they require version 16 (VS2019) which is not available when only have VS2017 (15) installed.

  • Yann Duran 0

    Hey Mads!

    Are there any plans for SDK-based VSIX project files?

    Same question almost a year later.

Feedback usabilla icon