VS Extensibility

Microsoft, the Visual Studio Shells and the old versions

2 Comments

Visual Studio 2008 started to offer a new form of extensibility: a whole IDE for your app! That is, reusing the core of the Visual Studio IDE for your own tool instead of reinventing the wheel creating a new IDE from scratch. This is named Visual Studio Shell and there are two flavors: the “Isolated Shell“, where your app has its own instance of Visual Studio Shell even if the Visual Studio IDE is already installed (because the user is a developer); and the “Integrated Shell“, where if the Visual Studio IDE is already installed, your Visual Studio Shell integrates with it (otherwise is installed anyway).

I have never worked with the Visual Studio Shell, nor I have any knowledge, but I provide a page on this site for the download links. Alas, it seems that Microsoft doesn’t pay much attention to keep the links working, so I get questions on forums and by email about their availability. If the links of that page fail, you can try the following:

It would be nice if Microsoft provided a centralized, public page with the downloads that VSX developers may require to develop and test extensions (Visual Studio SDKs, .NET Framework SDKs, Visual Studio Shells, Community editions, etc.) and, very important, from the current Visual Studio version going back to… Visual Studio 2005 and .NET Framework 2.0. Not everyone wants or can use the latest bits. I keep a couple of hard disks at home and at my basement with all the required Visual Studio versions, Visual Studio SDKs, Windows SDKs, .NET Framework SDKs, Windows OS versions,  etc. fearing that they would disappear from the web some day (which certainly is happening with the shells). And now that Microsoft uses web-based installers for Visual Studio with no .iso file provided, I am even afraid that my Visual Studio 2017 installer won’t work in a few years, so I have to create an offline installer.

The strange case of...

The strange case of VB6 getting “access denied” building ActiveX DLL running with Registry virtualization

This is one of those posts that I write mainly for myself in the future, but that maybe can be useful for others developers that want or need to run Visual Basic 6.0 without admin rights on Windows 7 or Windows 10.

One of the flavors of my MZ-Tools add-in is for Visual Basic 6.0 (yes, there is still quite a few people using it). Visual Basic 6.0 was created and used heavily in a time (Windows 98-Windows XP) when every Windows user was an administrator, so it was not a problem that when building an ActiveX DLL project some registry entries were added to the HKEY_CLASSES_ROOT (HKCR) registry hive, actually to HKEY_LOCAL_MACHINE (HKLM) internally. On Windows Vista and higher with the User Account Control (UAC) that changed, so if you run Visual Basic 6.0 without admin rights you get this error when building an ActiveX DLL:

A solution is of course to run Visual Basic 6.0 with admin rights, and I have been doing it so for some years. But that requires Visual Studio running also with admin rights, to be able to debug an add-in project loaded on Visual Basic 6.0 (if Visual Studio is not running with admin rights, it prompts you to restart with admin rights, but that’s quite annoying). But running Visual Studio all the time with admin rights only because of Visual Basic 6.0, when all the IDEs (Visual Studio, VBA) of my other add-ins wouldn’t require it, is somewhat overkill, and I really wanted to avoid it.

So, I was aware of the Registry virtualization mechanism of UAC, which Microsoft invented precisely for this scenario: an application that required admin rights to write in some keys of the HKLM\Software key of the Registry but that was not allowed to run with admin rights. Since Registry virtualization was not working for Visual Basic 6.0, my first thought was that it no longer existed on Windows 10 (documents say that apps cannot rely on this mechanism forever since it will be removed in some Windows version), or that it needed to be activated at global level. But no, if you open the Local Security Policy and go to Local Policies > Security Options, the setting exists and file and registry write failures are virtualized by default:

My second thought was that it needed to be activated per-application. But no, all the documents say the opposite, applications can disable registry or file virtualization by adding a .manifest, which signals to the Windows OS that the application is UAC-compliant (and therefore virtualization is not required). And indeed Process Explorer revealed that vb6.exe runs with virtualization:

So, what was happening? Process Monitor to the rescue. I noticed that Visual Basic 6.0 was trying to write to HKCR\TypeLib, getting “access denied”, not directly to HKLM:

But HKCR is actually a merged view of some keys of HKLM and some keys of HKCU, and clearly the failure was due to the HKLM side.

Finally, a closer reading of the page Registry Virtualization on MSDN, section Controlling Registry Virtualization, gave me the clue:  it happens that not all the keys of HKLM\Software are virtualized by default. In particular, the keys and subkeys of HKLM\Software\Classes, which are used when registering an ActiveX component, are not virtualized by default. Fortunately, you can use the reg.exe tool to query and virtualize them.

So I launched an elevated (with admin rights) command prompt and queried the HCKR\Classes\TypeLib (actually HKLM\Software\Classes\TypeLib) in 32-bit Registry (Visual Basic 6.0 is a 32-bit executable) with this command:

reg.exe FLAGS HKLM\Software\Classes\TypeLib QUERY /reg:32

Note: the fact that Visual Basic 6.0 is a 32-bit executable and that Process Monitor showed HKCR\TypeLib (that would belong to 64-bit) and not HKCR\WOW6432Node\TypeLib (that would belong to 32-bit) means that both keys (32-bit and 64-bit) are the same.

I got that it is not virtualized (REG_KEY_DONT_VIRTUALIZED: SET):

To clear that flag I executed the following, that clears the DONT_VIRTUALIZED flag but keeps set the RECURSE_FLAG as before:

reg.exe FLAGS HKLM\Software\Classes\TypeLib SET RECURSE_FLAG /reg:32

Trying to build again the ActiveX DLL causes the same “Error accessing the system registry”, but this time Process Monitor revealed that the problem was in HCKR\WOW6432Node\Interface:

Notice that in this case HCKR\WOW6432Node\Interface is shown, instead of HCKR\Interface, which means that the 32-bit and the 64-bit keys are different.

So I queried the flags with this command:

reg.exe FLAGS HKLM\Software\Classes\Interface QUERY /reg:32

And I got that certainly is not virtualized:

Again, to clear that flag I executed the following, that clears the DONT_VIRTUALIZED flag but keeps set the RECURSE_FLAG as before:

reg.exe FLAGS HKLM\Software\Classes\Interface SET RECURSE_FLAG /reg:32

Trying to build again the ActiveX DLL caused the same “Error accessing the system registry”, but this time Process Monitor revealed that the problem was in HCKR\Interface, so I executed:

reg.exe FLAGS HKLM\Software\Classes\Interface SET RECURSE_FLAG /reg:64

And finally building the ActiveX didn’t cause any error.

VS 2017, VS Extensibility, VS Packages

Migrating the build of a VSIX project to a build server if you are a solo developer

2 Comments

Some months ago I started a long and slow journey to migrate the build process of my MZ-Tools extension from a custom .NET-based builder that ran on my development computer to Visual Studio Team Services, leveraging its Build management and Release management capabilities. My goals are to learn those capabilities and, well, to use them as if I were a team. I haven’t reached yet that destination but I have made significant progress and I am quite close now. In the process I have realized somewhat ashamed that I wasn’t following the best practices in a lot of places. I say “somewhat” because there are some mitigating circumstances:

  • Being a solo developer it is too easy to arrange things in such a way that only works on your development machine. You don’t have a team to warn you that it doesn’t work outside your development machine.
  • Even if you change your development machine to a new one from time to time, or use two development computers, you use the same username and tend to install and configure the software in the same way.
  • My Visual Studio solution and some projects were born in the year 2002, with the first Visual Studio .NET. At that time Team Foundation Server, NuGet, MSBuild, etc. didn’t even exist on paper.
  • I have all the Visual Studio versions and VS SDKs from 2005 to 2017 installed on my development machine. That causes that you don’t think carefully where a DLL is referenced from.
  • I have also all the .NET Frameworks and SDKs from .NET Framework 2.0 installed on my development machine. Another source for undocumented hidden dependencies.
  • My Visual Studio solution has become quite complex over the years with several projects and technologies:
    • One project that uses .NET Framework 2.0 and C# for the core plug-in, that is reused at binary level for many Microsoft’s IDEs.
    • Four projects with host adapters for Visual Studio (2005, 2008, 2010) as add-in, VBA (Microsoft Office 2000 or higher, even on Windows XP), VB 6.0 and VB 5.0, using .NET Framework 2.0, C# and 3rd party tool for the setups.
    • One project with a host adapter for Visual Studio (2012, 2013, 2015 and 2017) as package, using .NET Framework 4.5, C#, and VSIX.
    • Four projects with COM Shims for VBA (32-bit and 64-bit), VB 6.0 and VB 5.0 using Visual C++, ATL, Windows 8.1 SDK and the .NET CLR loader APIs.
    • One project for a portable version for VBA, using .NET Framework 2.0 and C#.
    • Help file and online help generated by a 3rd party tool.
    • Two projects with integration tests.
    • Obfuscation performed by a 3rd party tool, that requires delay signing.

Microsoft tends to create a new VSIX with each new Visual Studio release but most of us want to create a single package and single VSIX for as many Visual Studio versions as possible, using always the latest Visual Studio version for development (Visual Studio 2017 at the time of this writing). If this is your case, even if your solution is not as complex as mine, ask yourself these questions:

In the process that I have followed first I envisioned the final result:

  • I would use the hosted agent of the Build management of Visual Studio Team Services to provide the following benefits:
    • Gated check-ins to prevent code that breaks the build.
    • Gated check-ins to prevent code that violates code analysis rules.
    • Integration tests. This will require a major effort because I use my own test runner and testing framework instead of Visual Studio Test with the MSTest framework.
  • I would use a private agent on the Release server with the Release management of Visual Studio Team Services to provide the following benefits:
    • Tracking of releases deployed to the test environment, to the pre-production environment and to the production environment.
    • Maybe automated releases.

For these purposes I decided that I would use a new “Build” configuration of the solution for the Build server. In this configuration the obfuscation, help file and online help, setups, etc. are not created. For the Release server I would use the “Release” solution configuration that performs all those additional steps.

For the Build server it is quite easy and I can use the hosted agent of Visual Studio Team Services since I don’t need any 3rd party tools.

For the Release server I cannot use the hosted agent because I need the 3rd party tools that I use to obfuscate, create the help, setups, etc. In the process I have also removed the need for admin rights that my custom builder required previously (the hosted agent of Visual Studio Team Services doesn’t allow admin rights either).

The milestones would be:

  • Migrate the custom .NET-based builder to a MSBuild script. This took me weeks but it’s done.
  • The solution and projects, when built in “Release” configuration, would auto-increment version numbers and would obfuscate the output assemblies, build the help, setups, etc. with their own MSBuild targets without requiring external steps.
  • A master MSBuild script would perform some additional steps before building the solution (such as creating a workspace, getting latest files, restoring NuGet packages, etc.) and some other steps afterwards (such as publishing and archiving binaries).
  • Build on a separate workspace on my development machine. Previously I was building on the same workspace used for development. I know, I know, a horrible bad practice.
  • Create a separate temporary virtual machine to act as Release server with only Visual Studio 2017 Community edition installed, without previous Visual Studio versions to identify missing dependencies and build with the master MSBuild script.
  • Discard the virtual machine of the previous step and create a new virtual machine with the Build Tools 2017 but without Visual Studio 2017, identify and install missing dependencies, build with the master MSBuild script and document everything. I have reached this point!
  • Install a private Visual Studio Team Services agent on the virtual machine that acts as Release server and launch the master build script from the Release management section of Visual Studio Team Services.
  • Create additional scripts to publish binaries to the pre-production and production environment rather than using manual FTP.
  • Repeat everything with the solution for my ASP.NET web site.

I encourage you to follow the same journey if you are a solo developer (and of course if you are a team). At the very least, the exercise of building on a separate build server with only Build Tools 2017 will unhide you hardcoded paths, references that are not provided by source control or supplied as NuGet packages, etc.

VS 2017, VS Extensibility, VS Packages

Microsoft now working on conditional payloads for VSIX. And for VS 2017 service release!.

1 Comment

Almost three years ago I created this request on Uservoice:

Conditions support for <Content> section of VSIX manifest

This request tries to solve a problem that is increasingly tricky: while Microsoft (or developers that work within Microsoft) release a new extension for each new Visual Studio version, most of us want desperately to update our existing extensions to support multiple versions of Visual Studio. Ideally we would like to have a single package DLL that targets many Visual Studio versions, but if you want to use the latest extensibility APIs, then most of the time you are forced to add references that demand a new package DLL because those references don’t exist on old versions of Visual Studio. But yet, we would like to ship those different package DLLs in the same unified VSIX file, so that for some versions of Visual Studio the VSIX file deploys a package DLL, and for other versions of Visual Studio the VSIX file deploys a different package DLL. Even you may want to deploy different .pkgdef files, as I explained in the request. And nowadays, with the release of Visual Studio 2017 and its manifest “v3”, we would like even different manifests (“v1” for Visual Studio 2010, “v3” for Visual Studio 2012-2017) within the same VSIX, which would solve the most common question on the forums these days: “How can I make a single VSIX that targets Visual Studio 2010-2017?” (sorry, you can’t).

Today, I have received an update from UserVoice indicating that Microsoft is now working on it, and that it will be “for a future servicing release of Visual Studio 2017”. Big news!!!

You can still vote for the idea to show user demand 🙂

VS 2017, VS Extensibility

3rd party database tools such as MySQL requiring some work to integrate with Visual Studio 2017

1 Comment

With the release of Visual Studio 2017, some popular database tools such as MySQL no longer appear in the Data Connections node of the Server Explorer even if you have installed current version of MySQL for Visual Studio 1.2.6:

It’s no wonder since if you select the Custom installation you will see that Visual Studio 2017 doesn’t appear yet in the list of possible Visual Studio versions to integrate with:

There is also some bad news: the integration with Visual Studio 2017 is more difficult than in previous versions. Third party database tools had two ways to integrate with Visual Studio using Data Designer Extensibility (DDEX):

The first one, which was valid until Visual Studio 2015, is to create some entries in the Windows Registry. See Registering a Registry-Based DDEX Provider. For data providers and data sources the entries are:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\<version>\DataProviders
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\<version>DataSources
Visual Studio merges later and redirects at run-time HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\<version> to HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\<version>_Config, but that’s transparent for the tool.

Since Visual Studio 2017 uses its own private Registry hive (see the Change: Reduce registry impact > Visual Studio registry section of Changes in Visual Studio 2017 extensibility) instead of the Registry entries similar to the ones used by older Visual Studio versions, the previous approach is no longer valid. If the setup of a DDEX provider uses RegLoadAppKey to create entries in that private Registry hive, Visual Studio could wipe out them later when it needs to generate its private Registry hive from .pkgdef files. So, for Visual Studio 2017, the only way is to use .pkgdef files, as explained next.

The second one is to create a .vsix extension (package) that provides enhanced design-time support and uses a .pkgdef file to create those registry entries. See Registering a Package-Based DDEX Provider. This is the approach used by MySQL. For Visual Studio 2015 you can see that it installs an extension in the folder:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Oracle\MySQL for Visual Studio\1.2.6.

In that folder you can find the MySql.VisualStudio.pkgdef that creates the registry entries:

So, Oracle needs to modify the MySQL package to support Visual Studio 2017. Alas, their vsix manifest is still using version 1.0:

and that is because they wanted to support Visual Studio 2010, 2012, 2013 and 2015 with a single .vsix file:

  • Visual Studio 2010 only supports manifests with version 1.0.
  • Version 2.0 was introduced by Visual Studio 2012, and it is not backwards compatible, so Visual Studio 2010 doesn’t support it.
  • While Visual Studio 2012, 2013 and 2015 support manifests with version 2.0, they also support manifests with version 1.0. So a single .vsix can target Visual Studio 2010, 2012, 2013 and 2015.
  • Visual Studio 2017 doesn’t support manifests with version 1.0. So, it is not possible to have a single .vsix for Visual Studio 2010, 2012, 2013, 2015 and 2017.
  • Instead, Visual Studio 2017 requires a manifest with version 3.0.
  • Fortunately, version 3.0 is backwards compatible with version 2.0 (version 3.0 adds a Xml entry that is only recognized by Visual Studio 2017 and ignored by previous versions. See section Changes Affecting VSIX Format and Installation). So, a single .vsix can target Visual Studio 2012, 2013, 2015 and 2017.

The bottom line is that two installers will be required for MySQL to target the last five versions of Visual Studio 2010-2017. It’s a pity that Oracle hasn’t used the previous months to make all these changes, frustrating its users.

VS Extensibility

Visual Studio turns 20, and its extensibility too!

Visual Studio is celebrating its 20th anniversary these days! Twenty years ago Visual Studio 97 was launched and on March 7 Visual Studio 2017 RTM has been released in a livestreamed two-day launch event at https://launch.visualstudio.com. You can share your story with Visual Studio with the hashtag #MyVSStory.

My story with Microsoft tools started some years earlier, in 1994. During college I learned Modula-2 (similar to Pascal), C and some C++. In my first job, my boss gave me a book and told me to learn Visual Basic 3.0 in two weeks, and I fell in love with the language and IDE in a couple of days, as soon as I saw a VBX control to show maps. VB3 lacked classes, intellisense and a lot of things, but it was very productive compared to C/C++. In 1996, VB4 was released, which came in two flavors, 16-bit and 32-bit, used OCXs and introduced classes, but no extensibility yet. In 1997 Visual Studio 97 was launched, which was a suite of separate IDEs, one for Visual C++, one for Visual Basic 5.0, etc. and for the first time, extensibility in the form of add-ins:

Only one year later, Visual Studio 6.0 was released with VB 6.0, that offered a very similar extensibility model. Next year, my company hired a contractor to develop an add-in to review the quality of the source code of our applications. These days of Visual Studio Code Analysis (FxCop), Roslyn analyzers, SonarLint, and tons of similar extensions we take this for granted, but in 1998 there was nothing. The contractor did a good job, but after he left I felt that I could improve the add-in, so I learned the extensibility model of VB6 and I fell in love again :-). I ended developing my own add-in with new features that I released as freeware on the web.

During almost three years, from 1998 to 2001, Microsoft didn’t release a new Visual Studio, and for a good reason. The .NET Framework initiative was announced in 2001, and finally in February 2002 a brand new Visual Studio .NET was released, a unified IDE for VB.NET, Visual C++, a new language C#, etc. I learned .NET during 2002 (I fell in love again…) and the new automation model (EnvDTE) provided by the new IDE, that was completely different to the one of VB6 but inherited some strange details such as collections starting at 1 and not at 0. Visual Studio .NET 2002 provided add-ins, templates, wizards, and a new extensibility mechanism named Macros that allowed to record or to code by hand procedures to execute repetitive actions. But it didn’t provide support to create packages, nor a SDK. From the extensibility point of view, it had some oversights, such as requiring add-ins to be COM components (and therefore using COM Interop if written in a managed language instead of C++) and requiring a COM Shim (an ActiveX control developed in C++) to host managed toolwindows (and the provided COM shim had lots of problems with the tab key navigation, etc.).

Only 14 months later, in April 2003, Microsoft released Visual Studio .NET 2003, which introduced for the first time VSIP (Visual Studio Integration Program), a kind of SDK (not named as such yet) to develop native packages in C++. Later a VSIP Extras was released to use manage languages (C# at least).

Two years later Visual Studio 2005 was released, which was a great release. It introduced .NET Framework 2.0, MSBuild, and important novelties in the extensibility area: it provided a proper VS 2005 SDK for the first time, it allowed to develop packages in managed languages using the Managed Package Framework (MPF), it allowed XML-based add-ins (using an .AddIn file instead of COM-registration), it didn’t require COM shims for toolwindows, and it was gorgeous with its 24-bit color toolbars.

(In November 2006 I started to blog about Visual Studio Extensibility (VSX) with add-ins).

Visual Studio 2008 was the next release, which didn’t introduce anything remarkable in the extensibility area, but Microsoft introduced in February 2008 the Visual Studio Gallery:

And then Visual Studio 2010 was released, which, for me, has been the best and more beautiful Visual Studio ever released, despite the insane amount of problems that caused to developers of add-ins during the betas because new Windows Presentation Foundation (WPF)-based commandbars were introduced. From the extensibility point of view, add-ins didn’t require a satellite dll for custom pictures any more, the Managed Extensibility Framework (MEF) was introduced to extend the new code editor (which was WPF-based too), changed the .ctc format to define commands and commandbars to the .vsct file that is used still today and introduced the VSIX packaging format to deploy extensions (except add-ins). It also introduced the Extension Manager:

Two years later Visual Studio 2012 was introduced, which arguably has been the most unfortunate Visual Studio version ever released. It removed colors from the user interface (and even separation lines during the betas), it used upper-case top menus (all of this despite tons of complains) and from the extensibility point of view, it removed macros, a very controversial decision that reached 6,000 votes to bring them back on UserVoice (something that happened some years later in the form of an extension for VS 2013/2015).

I think that even Microsoft realized that Visual Studio 2012 was quite disappointing, because it released Visual Studio 2013 very fast, only a year later instead of the usual 2 or 3-year cycle. Some color was brought again with themes (not too enough color for me, though), but, alas, for developers of add-in there was bad news: add-ins were still present, but officially deprecated. Packages were the primary form of extensibility for Visual Studio and finally Microsoft decided it was time to get rid of add-ins. Retrospectively I am glad of that decision because it forced me to learn packages, but it was a huge amount of work that required some thought and strategies. Visual Studio 2013 introduced big news for all developers: a free Community Edition that supported extensions, on the contrary to the former Visual Studio Express editions, a common request on UserVoice.

Visual Studio 2015 was released two years later, effectively removing add-ins. The venerable Add-In Manager of Visual Studio since the year 2002:

was removed and the Extensions and Updates dialog became the central window for extensions:

Visual Studio 2015 also brought us async packages, new ruled-based UI contexts, the Image Service and Catalog to eliminate major pain points related to asset maintenance, high DPI scaling, and theming and a huge Visual Studio Image Library. It also provided “Roslyn”, that is, the C# and VB.NET compilers as platform, and open source, so you can leverage them to build Roslyn analyzers (live code analysis without building) and code fixes.

The Visual Studio 2017 version that was released on March 7 provides the Roaming Extension Manager, something that was available originally for Visual Studio 2015 as an extension. It also provides also a very light setup, very isolated and resilient, that requires some changes in extensions. A handy feature for VSX developers is that now the Community, Professional and Enterprise editions can coexist on the same computer, which allows you to test your extensions on all those editions without requiring additional computers or virtual machines.

Finally, the Visual Studio Gallery is in the process to be transformed into the Visual Studio Marketplace. For Visual Studio currently it only allows to download extensions, while the publishing is still done on the Visual Studio Gallery, something that will be migrated in the next months.

For many years VSX was hard due to difficult APIs and lack of documentation and support, but now you have much better documentation, tons on samples on GitHub, including real extensions, tons of VSX developers, and several forums such as the veteran MSDN Visual Studio Integrate forum (still my favorite that I visit daily), StackOverflow or the more recent and very active Gitter (Microsoft/extendvs) chat room.

So, it has been a long journey for Visual Studio extensibility until today and likely I have forgotten some milestones. But one thing is sure: this is the best moment to be a VSX developer. Happy Birthday, Visual Studio!

VS Extensibility

More on DPI-awareness

I already blogged about Visual Studio extensions and DPI-awareness, where I detailed my experience converting my MZ-Tools extension to DPI-awareness for the most part (I haven’t updated the toolbar buttons yet because the required API only works on VS 2015 and higher).

I also mentioned how to run Visual Studio or setups with DPI virtualization (DPI-unaware) on high DPI displays, to overcome some display problems that can happen designing Windows Forms or running some old SDK setups.

My problems didn’t end there, though. One of my customers reported me a bug that happened when using a laptop with a retina display connected to a non-retina external display. I was familiar with the problem because I have suffered it too, since I own a Surface Pro 4 with a dock station that uses a non-retina display. With some combination of undocking / restart / docking, I could end with this problem using MZ-Tools 8.0 for VBA in the VBA editor of Office (click to enlarge):

I thought that I was the only person with that problem but after the bug report I knew it affected other users. Also, I noticed that when the problem happened, Notepad++ was also affected in the document tabs, and it was already reported here, here and here:

My add-in uses Windows Forms, but Notepad++ uses GDI, so it is not a problem of Windows Forms but of GDI.

Aa a workaround, I had to change all the forms and usercontrols of my add-in to detect if the font was “too big” and in such case adjust its size. Technically, the System.Drawing.SystemFonts.DefaultFont is returned huge. It happens that internally it calls GetStockObject(DEFAULT_GUI_FONT), which according to MSDN is not recommended. So, if the add-in detects that the font of the form/usercontrol is much bigger (say, two points) than the size of System.Drawing.SystemFonts.MessageBoxFont (which is not affected by the problem), then it changes the size. The problem is convoluted by the fact that I cannot reproduce it at will.

It seems that the DPI-awareness problem is so pervasive that Microsoft has invested a lot of work to fix or alleviate it on the Windows 10 Anniversary Update introducing the concept of “Mixed-Mode” DPI scaling, also known as sub-process DPI scaling, via the concept of the DPI-awareness context (MSDN documentation here) and I am glad to see that the investment will continue heavily on the new Windows  10 Creators Update, due later this year, that will introduce new enhancements, including a new DPI-awareness context (“Per-Monitor V2”), automatic DPI scaling for GDI-based apps, new Windows Forms DPI scaling improvements (for people like me still using Windows Forms) and other improvements for Internet Explorer and Windows desktop icons (that I suffer too). You can watch the following video by James Clarke and Peter Felts explaining the improvements and showing cool demos (new post and sample to follow soon):

VS 2017, VS Extensibility

Using VSIXInstaller.exe to install programmatically an extension to Visual Studio 2015 and Visual Studio 2017

9 Comments

Answering a question in the MSDN VSX forum today, I have learned another change caused by the new VSIX installer (VSIXInstaller.exe) of Visual Studio 2017 that it is worth documenting here.

As you know, in Visual Studio 2015 only one edition (Community, Professional or Enterprise) could be installed on the same machine. Two or more editions couldn’t coexist at the same time. Given that the Enterprise edition includes the features of the Professional edition and that the Community edition is basically the Professional Edition (without some feature such as CodeLens), the VSIX manifest of your extension could target the “Pro” edition and as such it would be installable on any edition (Community, Professional or Enterprise):

Normally a .VSIX file is installed just double-clicking it, so that the VSIXInstaller.exe application is launched. But if you want to install an extension programatically, the VSIXInstaller.exe application offers a few command-line switches:

Notice the /skuName:<name> option: it allows to specify the exact edition (Enterprise, Premium, Pro, Community, etc.) of Visual Studio where you want to install the extension. Which value you would need to use? It happens that for Visual Studio 2015, you can use “Pro” and the extension will be installed happily not only on Visual Studio 2015 Professional, but also on Visual Studio 2015 Community or  (Updated March 1, see comments section) Visual Studio 2015 Enterprise. For example, installing my MZ-Tools extension on Visual Studio 2015 Enterprise edition with this command line works perfectly:

vsixinstaller.exe /skuName:Pro /skuVersion:14.0 “<path>\MZTools8VSPackage.vsix”

(notice that it recognizes my Enterprise edition as Professional edition).

However, the same is not true for VS 2017. Using this command line to install it on my Visual Studio 2017 Enterprise edition:

vsixinstaller.exe /skuName:Pro /skuVersion:15.0 “<path>\MZTools8VSPackage.vsix”

causes this error:

The following command-line is required, targeting specifically the Enterprise edition:

vsixinstaller.exe /skuName:Enterprise /skuVersion:15.0 “<path>\MZTools8VSPackage.vsix”

So, this is another implication of the new modular setup of Visual Studio 2017 for VSX developers. You can query the installed VS 2017 editions with a new Setup API (sample included).

VS 2017, VS Extensibility

Videos and extensions by Justin Clareburt, Program Manager in Visual Studio Extensibility

Justin Clareburt, Program Manager in Visual Studio Extensibility, and super passionate about VSX and super active in the Microsoft/extendvs Gitter room to help you to update successfully your extension to Visual Studio 2017, has also time to produce videos and to create extensions!:

The first video is with Seth Juarez, about using keyboard mappings in Visual Studio:

And his “hot” extensions:

– Hot Keys: Visual Studio Extension that imports several new keyboard mapping schemes http://aka.ms/hotkeys

– Hot Commands: Provides additional commands and shortcuts for enhanced productivity http://aka.ms/hotcommands

The second video is with Robert Green (Visual Studio Toolbox) about updating your extension to the new Visual Studio 2017:

VS 2017, VS Extensibility

Microsoft.VSSDK.BuildTools 15.0 no longer in Preview/Release Candidate

Just in case you haven’t noticed it, the NuGet package for Microsoft.VSSDK.BuildTools 15.0 is no longer Preview or Release Candidate (RC, RC2 or RC3) but final release:

As you can see, it has been a long way of previews / RCs to reach this point:

So, it’s time to update that NuGet package and rebuild. Microsoft hasn’t announced yet the release date of the final version of Visual Studio 2017 but it seems that we are approaching that date, at least from the Visual Studio Extensibility point of view. Update (Feb 10): the launch date has been announced for March 7. If you haven’t updated your extension to support VS 2017 yet, the clock is ticking. Here you have the guidance to do it.

VS SDK, packages, add-ins, macros and more…