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 MergeWithCTOMSBuild 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())
{
    form.ShowDialog();
}

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 AsyncPackagewith 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

Senior Program Manager, Visual Studio Extensibility