Category Archives: VS Packages

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

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 🙂

SAMPLE: How to create a Visual Studio context menu

For the sake of completeness, I have added another sample to the list of samples about creating top menus, submenus, toolbars, etc. that I created a few days ago on GitHub:

HOWTO: Create a Visual Studio context menu
Demonstrates how to create a context menu that is shown when right-clicking on a toolwindow. To show the toolwindow click the View > Other Windows > My toolwindow command.



That is, in this case we don’t want to add a menu entry to an existing context menu, but we want to create a whole context menu with entries to be shown when right-clicking on something, typically a control of a modal dialog or a toolwindow that belongs to our package.

There are a couple of ways to accomplish this:

The first one is using automation (EnvDTE): you create by code a commandbar that you show using the CommandBar.ShowPopup method. This was the only approach for add-ins and you have a sample in the article HOWTO: Create a context menu using a Visual Studio commandbar popup from an add-in. Since packages can use DTE, this approach is suitable. The commandbar can even have menu entries without an underlying command. But this approach is not the focus of this post.

The second one, only for packages, is using a .vsct file. The Menu element of the .vsct file can be of several kinds, and one of them is “Context”. Then you add commands to it through a group, like any other type of menu. But how is shown?. You need to use either the IOleComponentUIManager.ShowContextMenu method or the IVsUIShell.ShowContextMenu method. I have used the latter method, which receives several parameters such as the Guid of the command set, the Id of the context menu (both defined in the .vsct file) and the point where to show it.

The sample also shows the correct approach to initialize the usercontrol of a toolwindow (to pass it the package). Take into account that a toolwindow in Visual Studio can be shown in two cases:

  1. Clicking the command that shows the toolwindow.
  2. Automatically when Visual Studio is launched if the toolwindow was shown when Visual Studio was closed the last time. Visual Studio is smart enough to know the package owner of the toolwindow to show, then it loads the package and shows the toolwindow.

The initialization of the usercontrol cannot be done in the constructor of the toolwindow when the usercontrol is created because at that point the base.Package is null in the case 2:

public MyToolWindow() : base(null)
   this.Caption = "My toolwindow";

   m_toolWindowControl = new ToolWindowControl();

   this.Content = m_toolWindowControl;

Instead, you need to override the OnToolWindowCreated method since at this point the base.Package is already initialized:

public override void OnToolWindowCreated()
   VSPackageContextMenu package;


   package = (VSPackageContextMenu)base.Package;


The strange case of System.NotImplementedException “The method or operation is not implemented.” using SQL Server database projects

Yesterday I got a bug report from a user of my MZ-Tools package for Visual Studio 2015:

System.NotImplementedException “The method or operation is not implemented.”

The exception happened calling the EnvDTE.ProjectItem.IsOpen Property (viewKind) method when using SQL Server Database Projects provided by SQL Server Data Tools (SSDT):


As you may know, SQL Server Database projects are quite good automation-friendly projects, that is, they implement EnvDTE interfaces (EnvDTE.Project, EnvDTE.ProjectItem, etc.) so you don’t need to use the low level IVsHierarchy, etc. interfaces of Visual Studio. But somehow, they missed to implement something somewhere.

I tried to reproduce the problem on my side to no avail. My extension worked happily with the .sql files (EnvDTE.ProjectItem) of that kind of project. So, which kind of EnvDTE.ProjectItem didn’t implement the IsOpen property? The user sent me a helpful clue: he was using a database reference. I was not aware of that thing, but certainly in SQL Server database projects you can add references to databases:


And as soon as I added a reference to the “master” database, I could reproduce the problem. So, my extension was treating the ProjectItem nodes below the References node as files that could be “opened”, and the ProjectItem.IsOpen method was not implemented (which is certainly right). But, how is that the nodes below the References node were being processed for database projects (which is incorrect) while they were not processed for regular (C#, VB.NET) projects?. The reason is that for regular projects, the EnvDTE.Project.ProjectItems collection of the project doesn’t return the References node, which is correct. For database projects, the EnvDTE.Project.ProjectItems collection does return the References node, which is a bug. I wanted to verify that the internal implementation of database projects has this bug so I used .NET Reflector to see the internals of the Microsoft.VisualStudio.Data.Tools.Package.dll package and I found that there is a ReferenceContainerNode type that has a GetAutomationObject that returns an OAReferenceFolderItem instance:


There shouldn’t be a folder for references in the automation model (EnvDTE). The automation model provides the VSLangProj.References collection to handle the references of a project. I won’t report the bug because there is an almost zero chance of Microsoft fixing it, and anyway I needed to find a fix for the current version of the SQL Server Data Tools, which took me to the next problem: how can an extension identify reliably the “References” ProjectItem?.

I could check if the Name property of the ProjectItem is “References”, but that approach is always prone to errors due to localization (in Spanish would be “Referencias”). The SQL Server Data Tools doesn’t seem to be localized, but I wanted to investigate another approaches. It happens that the IVsHierarchy of the References node implements an interface named IReferenceContainer. So, one could cast that node to IReferenceContainer and if the cast is successful then it’s the References node. Alas, that interface is declared internally in database projects, and in MPF.Project.NonShipping.dll for other projects. At the end, I opted for getting the EnvDTE.ProjectItem.Object property, convert it to a string, and compare it to “Microsoft.VisualStudio.Data.Tools.Package.Internal.OAReferences”, which is as bad as comparing the Name to “References”, but anyway, it works for now.

SAMPLES: How to create top menus, sub menus, context menus, toolbars

The questions of how to create a toolbar, a top menu, a sub menu, an entry on a context menu, etc. appear from time to time on the forums, so I have created a bunch of samples on GitHub:


They use what I consider best practice: the use of the CommandPlacements section in the .vsct file for centralized place to set parent-child relationships.

The code samples are the following:

HOWTO: Create a Visual Studio toolbar
Demonstrates how to create a toolbar.


HOWTO: Create a Visual Studio top menu
Demonstrates how to create a top menu.


HOWTO: Create Visual Studio commands on a submenu
Demonstrates the use of the CommandPlacements section of the .vsct file to place a command inside a new group on a submenu inside a new group on the Solution context menu and on the Standard toolbar.



HOWTO: Create a Visual Studio command on the Solution context menu
Demonstrates the use of the CommandPlacements section of the .vsct file to place a command inside a new group inside the Solution context menu.


HOWTO: Create a Visual Studio command on the project context menu
Demonstrates the use of the CommandPlacements section of the .vsct file to place a command inside a new group on the context menu of a Windows project, Web project, or multiple projects selected.


HOWTO: Create a Visual Studio command on the file context menu
Demonstrates the use of the CommandPlacements section of the .vsct file to place a command inside a new group on the context menu of a file or multiple files (belonging to the same project, or to different projects).


HOWTO: Create a Visual Studio command on the code window context menu
Demonstrates the use of the CommandPlacements section of the .vsct file to place a command inside a new group on the code window context menu.


SAMPLE: How to create a Visual Studio command that accepts parameters

Some weeks ago a user of my MZ-Tools add-in asked me how to automate the Review Quality feature. So far, this feature could be invoked on demand, or automatically when an output file is built using the user interface. The request was very reasonable: automated reviews when the code is built using some script, or when code is checked-in in source control (not in the context of a build). So, the requirement is to execute some feature programmatically with input parameters (feature name, log file, etc.) and generate output files (results file, log file, etc.). My last attempt at automating some feature of MZ-Tools was in 2007, when I wrote the post Frustrations with command-line add-ins for Visual Studio. So, it was time for another attempt.

If you try to execute a command with arguments, for example in the Command window, likely you will get this error:


It happens that there are four steps that you need to code to ensure that your command accepts parameters:


Rather than listing the steps here, I have created a sample on GitHub:

HOWTO: Create a Visual Studio command that accepts arguments

One of the steps (the magical “$” value that must be assigned to the ParametersDescription property of the OleMenuCommand) is so esoteric that it’s not properly documented anywhere, but some comments of Ryan Molden in a forum explains something about it.

The four versions of a Visual Studio package

One of the confusing aspects when you create a new Visual Studio package is that there seems to be many places where a version number appears. They are the following:

  1. The version on the Tools > Extensions and Updates dialog:


2. The version on the Help > About dialog:


3. The version on the deployment folder:


4. The version of the file:


5. The version of the assembly:


All those five versions are set in four places, that are the following:

1. The version on the Tools > Extensions and Updates dialog and the version on the deployment folder are the same version and it is set in the source.extension.vsixmanifest file, Version field. It is recommended (in my opinion) to set it to the file version (4 numbers):


2. The version on the Help > About dialog is set in the package class, InstalledProductRegistration attribute. It is recommended to set the same value than in the previous point, so that the Help > About and the Tools > Extensions and Updates dialogs show the same value:


3. The version of the file is set in the AssemblyInfo.cs file, AssemblyFileVersion attribute. This file version is a Win32 concept (not a .NET concept) and it is best practice to change it on each build:


4. The version of the assembly is set in the AssemblyInfo.cs file, AssemblyVersion attribute. This assembly version is a .NET concept and it is not required to change it on each build:


Note: to learn the difference between Assembly File Version and Assembly version read the Knowledge Base Community article How to use Assembly Version and Assembly File Version.

Resources to create high-DPI images with the new Visual Studio 2015 Image Service

In my post Visual Studio extensions and DPI-awareness I introduced the basics that you need to know to become DPI-aware. The final step once all the user interface of your extension handles high-DPI gracefully is to provide high-DPI images for the toolbars, as Visual Studio 2015 does since CTP 3. Apparently, support for high-DPI images through a new image service was in the Visual Studio 2015 RTM release, but it hasn’t been until a couple of days ago that Microsoft has published the MSDN documentation. Here you have the resources to learn and use it:

UPDATE (Jan 26, 2016): The Visual Studio Image Library, which contains .zip files with VS images, has been updated with VS 2015 images.

Announcing unified MZ-Tools 8.0 for Visual Studio, VBA (64-bit/32-bit), VB6 and VB5

It has been a long time since my last post here, and for a good reason. Since I released MZ-Tools 8.0 for Visual Studio 2015 last July 1 (converted from add-in to package), I have been very busy the last months to achieve a new huge milestone:

Announcing unified MZ-Tools 8.0 for Visual Studio, VBA (64-bit/32-bit), VB6 and VB5

From the extensibility point of view, MZ-Tools 8.0 is a unique piece in the world, AFAIK: it provides the same feature set for four different IDEs (Visual Studio, VBA editor, Visual Basic 6.0 and Visual Basic 5.0) with different extensibility APIs reusing the same code at binary level:

MZ-Tools 8.0 for Visual Studio (as package):

MZ-Tools 8.0 for Visual Studio (as add-in):

MZ-Tools 8.0 for VBA:

MZ-Tools 8.0 for VB6:

MZ-Tools 8.0 for VB5:

As you can see in the images, in all cases there is the same big MZTools8PlugIn.dll file, which contains the feature set, and smaller host adapter dlls that “plug” the features into the IDEs. If you are interested, I outlined the strategy to achieve this in this other post.

The strange case of CreatePkgDef failing because of strong name validation

After several days fixing bugs of my new MZ-Tools 8.0 version, today I have tried to run the build process that I have to generate the “Production” version and it has failed with this chain of errors:

Error 1 CreatePkgDef : error : ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. MZTools8VSPackage

Error 2 at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) MZTools8VSPackage

Error 3 at System.Reflection.RuntimeModule.GetTypes() MZTools8VSPackage

Error 4 at System.Reflection.Assembly.GetTypes() MZTools8VSPackage

Error 5 at Microsoft.VisualStudio.Tools.CreatePkgDef.ProcessAssembly(String fileName, Hive hive, PkgDefContext context, Boolean register, RegistrationMode mode) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 260 MZTools8VSPackage

Error 6 at Microsoft.VisualStudio.Tools.CreatePkgDef.DoCreatePkgDef(InputArguments inputArguments) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 164 MZTools8VSPackage

Error 7 at Microsoft.VisualStudio.Tools.CreatePkgDef.Main(String[] arguments) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 85 MZTools8VSPackage

Error 8 Could not load file or assembly 'MZTools8PlugIn, Version=, Culture=neutral, PublicKeyToken=a756ad4bac8a0579' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) MZTools8VSPackage

The first thing I noticed is that the errors show a location “f:\dd\VSSDK\VSIntegration\Tools\src” that is not on my hard disk. This is because the VS SDK tools (at C:\Program Files (x86)\Microsoft Visual Studio 12.0\VSSDK\VisualStudioIntegration\Tools\Bin) are shipped with the .pdb files for debugging.

The second thing that I noticed is that the CreatePkgDef.exe utility was failing because of a strong name validation that happened in the System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) method of the .NET Framework. However, this had been working until a few days ago. My MZ-Tools package (MZTools8VSPackage.dll) uses .NET Framework 4.5 and it is not obfuscated, but it uses a core MZTools8PlugIn.dll that uses .NET Framework 2.0 and it is obfuscated. So, the things are arranged as follows:

  • In “Debug” configuration, the MZTools8PlugIn.dll assembly is generated with a strong name because no obfuscation is performed.
  • In “Release” configuration, the MZTools8PlugIn.dll assembly is delay-signed, because it requires obfuscation, and you can’t alter an assembly signed with a strong name. So, obfuscation is done in a post-build step and then the obfuscated assembly is finally signed. The details are documented here.

So, in “Release” configuration, CreatePkgDef.exe is failing because the package assembly is loading a required assembly that doesn’t have a strong name yet (delay-sign). I was well aware that normally you need to instruct the .NET Framework to skip strong name validation using sn.exe -Vr (which for sn.exe 32-bit adds a special registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification) but somehow the CreatePkgDef step of the package assembly compilation of my build process has been working for ages until a few days ago without that strong name validation skipping step.

What has changed in the last days? My only suspect was Visual Studio 2015 and .NET Framework 4.6, that I installed on my main dev machine once they got RTM status. Since .NET Framework 4.5, 4.5.1, 4.5.2 and 4.6 are “highly compatible” with .NET Framework 4.0, they are not installed “side by side” but “on top” of the previous version. But it could be that one version introduces a breaking change to existing apps. To verify this hypothesis, first on my main dev machine where the issue was happening I created a package with Visual Studio 2008 (which uses .NET Framework 3.5 and CLR 2.0) and it compiled even setting the following delay sign in the AssemblyInfo.cs file:

[assembly: AssemblyDelaySign(true)]

The same was not true if I used Visual Studio 2010 or higher (which use .NET Framework 4.0 / CLR 4.0 or higher), but it was true in the past. So the suspicion increases.

Then, I setup a new virtual machine with only Visual Studio 2013 (.NET Framework 4.5.2) and lo and behold, a package compiles even if you use delay sign:


As soon as I downloaded and installed  only .NET Framework 4.6 (no need to install Visual  Studio 2015), the same package compilation gets this error:

CreatePkgDef : error : FileLoadException: Could not load file or assembly 'VSPackage1, Version=, Culture=neutral, PublicKeyToken=69b8a83eb37e3459' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)


So, .NET Framework 4.6 introduces a breaking change that I have not seen documented.

Now, there is at least a couple of solutions:

  • You can build the package assembly with a strong name even in “Release” configuration, so CreakePkgDef doesn’t fail, and remove the strong name before obfuscating. Since the sn.exe utility doesn’t allow to remove strong names, you must search some other utility on the web (they exist).
  • You can instruct the .NET Framework to skip strong name validation using sn.exe -Vr before the package assembly is built, not after the package is built and before the assembly is obfuscated. The utility sn.exe is so handy that it allows you to skip strong name validation for assemblies that don’t exist yet, specifying just the public key token that will be used to sign them:
sn.exe -Vr *,public_key_token

Visual Studio 2015 RTM just released

Finally Visual Studio 2015 RTM has been released today and I am installing now on my main dev machine, rather than on separate virtual machines as I have been doing until now. There is and there will be a lot of information about what’s new in this release, but as a developer of extensions for Visual Studio, this release introduces these changes that you must know:

  • Add-ins are gone and now packages are the primary way of extending Visual Studio for the typical need of creating some toolbar, menu, buttons, toolwindows, etc. or listening to events to do something. Migrating from an add-in to a package is not trivial due to the usage of services instead of the EnvDTE automation model (although you can still use the automation model) but also for the difficulties of the .vsct file. ElektroStudios StackOverflow user (and others): I do feel your pain. I will do my best to find time and provide decent tutorials and a GitHub sample about .vsct in the next couple of months.
  • The editions offering has been simplified a bit and now you have:
    • Community Edition, which supports extensibility and is free for some scenarios, at least “still free”, huh?
    • Professional Edition
    • Enterprise Edition
      All of them are already available. There is no Ultimate edition, but for some reason there are still Express editions for Windows Desktop, Web (both already available) and Windows 10 (coming soon).
  • The compilers for C# and VB.NET are now exposed to extensions through the .NET Compiler Platform (formerly “Roslyn”). This should replace the automation code models (EnvDTE.Project.CodeModel, EnvDTE.ProjectItem.FileCodeModel), although they can be still used and in fact their implementation has changed to use Roslyn under the hood, with quite a few bugs along the way that I have reported and most of them are fixed now.
  • There is new support for high resolution icons on buttons for high-dpi displays, although AFAIK it is not documented yet.
  • There is a new Common Project System (CPS) in the works.
  • The Visual Studio 2015 SDK is available as a separate download as until now, but it is also already included in the Visual Studio setup under the name Common Tools > Visual Studio Extensibility Tools:
  • The way to create a package, to add commands and toolwindows has changed, as hinted in the setup:
  • To create a package there is no longer a wizard as in Visual Studio 2013, but just a barebone VSIX project template, and later you add as many custom commands or custom toolwindows as you want using the Add > New Item dialog and selecting the corresponding item templates under the Extensibility node. This solves the old problem of how to add a second command or toolwindow to an existing package, at the cost of making it more difficult to know how to add the first ones.

I will elaborate on all these aspects in the next weeks (during my vacations, I’m afraid), and will provide new links on this site to VS 2015 specific stuff.

Did I mention that my extension MZ-Tools 8.0 is now a package for VS 2012, 2013 and 2015? It is also an add-in for VS 2005, 2008 and 2010, and they share 80% of code at binary level using the strategy of core plug-in +  host adapters that I outlined here. I have even released in the last weeks a restricted Beta 2 of MZ-Tools 8.0 for the VBA editor of Office and even for VB6 / VB5 sharing the same 80% of binary .NET code. This is an example of a complex add-in migrated to a package with a new good underlying architecture to accommodate not only future changes in the extensibility model of Visual Studio, but also to support other Microsoft IDEs.