New features for extension authors in Visual Studio 2019 v.16.1

Original author: Mads Kristensen
  • Transfer
At the beginning of last week, we released Visual Studio 2019 v.16.1 Preview 1 (see release notes ). This is the first preview of the first Visual Studio 2019 update. If you have not yet configured to receive Preview versions, then do it now . The Preview version is installed without problems next to the Release version, so that they do not interfere with each other. I highly recommend that all extension authors install the Preview version.

Do you currently have 16.1 Preview installed? Wonderful. Here are some features you might like. Details under the cut!



Shared Project Support


There are several reasons why extension authors sometimes have to split an extension into several projects to support different versions of Visual Studio. If you are using an API that did not exist for an earlier version of Visual Studio, or if there are significant changes between the versions you want to support. Now it has become much easier to split the extension.

In Visual Studio 2019 v.16.1 Preview 1, we added support for references to the Shared Project from VSIX projects in the same solution.

image

You can put common code in a separate Shared Project, which compiles directly into VSIX projects at build time. The only code that then exists in the VSIX projects themselves is the specific code for the supported version of Visual Studio. The result is two separate VSIXs that target their own range of Visual Studio versions and share most of the code from a common project. Check out the code for the Extension Manager extension that does just that.

No more need for a .resx file


When adding commands, menus, etc. using a VSCT file, you must specify the .resx file marked with the MergeWithCTOMSBuild property . Templates in Visual Studio take care of adding this file, and also add the .ico file referenced by the .resx file. However, the need for .resx is an implementation detail, and most extensions do not need to use it.

To simplify the VSIX project, the .resx /.ico file requirement has been removed for those using the latest NuGet package Microsoft.VSSDK.BuildTools 16.0 or later.

Behind the scenes, the NuGet package provides an empty .resx for compilation with the MergeWithCTO property until you register your own in the project.

Per-monitor awareness


Additional per-monitor support is included in 16.1 with the .NET Framework 4.8 installed. Windows Forms UI is now better at DPI scaling on monitors. However, this may cause UI problems in your extension after installing the .NET Framework 4.8.

When using Windows Forms in an extension, you can map the scaling behavior of Visual Studio 2017 by packaging the creation of your form or control in DpiAwareness.EnterDpiScope .

using (DpiAwareness.EnterDpiScope(DpiAwarenessContext.SystemAware))
using (var form = new MyForm())
{
    form.ShowDialog();
}

All you need to do is add a link to the NuGet package Microsoft.VisualStudio.DpiAwareness . Use this package in extensions targeting earlier versions of Visual Studio, but keep in mind that it will only work when used in version 16.1 and later. Therefore, it can be used in extensions that span multiple versions of Visual Studio.

To simplify the simulation of several monitors working with different DPI scaling, the engineer from the Visual Studio IDE team created a small convenient tool and put it on GitHub . The team used this tool when they added support for per-monitor awareness, so you can find it useful too.

Read more on how to work withPer-Monitor Awareness .

Synchronous startup disabled


18 months ago, we sent an email to extension partners, announcing the obsolescence of synchronous startup of extension packs. A year ago, we published a blog post with more detailed information that the synchronously autostart package will not be supported in a future version of Visual Studio. This version is 16.1.

There are great examples of how to upgrade to AsyncPackage with background loading enabled, and most extensions today have already transitioned. If you have not already done so, now is the time to do it before 16.1 leaves the preview mode.

New metapackage SDK


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

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

The good news is that we are now finally ready for version 16.0. If your extension supports version 16.0, then you should use it. You can also learn more about extension versions here .

Also popular now: