New features for extension authors in Visual Studio 2019 version 16.1

Mads Kristensen

Mads

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.

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.

Mads Kristensen
Mads Kristensen

Senior Program Manager, Visual Studio Extensibility

Follow Mads   

17 Comments
Avatar
t r 2019-04-11 15:25:01
Need native C++ sample for AsyncPackage extension!
Avatar
Stan Wijckmans 2019-04-12 03:53:12
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
Mike Ward 2019-04-12 06:39:56
So just to be clear, extensions that don't implement AsyncPackage will stop working in 16.1?
Avatar
Guy 2019-04-12 10:14:21
I have a new feature, well it is an old feature, that can become new again. Get rid of Extensions menu and bring back Top Level Menus https://developercommunity.visualstudio.com/idea/435711/get-rid-of-new-extensions-menu.html
Avatar
Carlos Quintero 2019-04-12 11:17:03
Hi Mads, Could your team create an official standalone NuGet package for the VsWebSite.Interop.dll 8.0.0.0 assembly used in automation/extensibility for web sites (introduced in VS 2005) that EnvDTE80 doesn't cover? (See https://docs.microsoft.com/en-us/previous-versions/ms778694(v%3Dvs.140) 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
Avatar
Marat Abdullaev 2019-04-12 18:45:05
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
Matthieu Penant 2019-04-19 11:24:23
Are there any plans to make PackageReferences available for VS.Extension projects?
Avatar
André Ziegler 2019-05-08 22:50:07
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=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'at So they require version 16 (VS2019) which is not available when only have VS2017 (15) installed.
Avatar
Yann Duran 2019-05-17 22:01:01
Hey Mads! Are there any plans for SDK-based VSIX project files?