Category Archives: VS Packages

VS Packages

New articles about VSIX and Pkgdef added to website

Since one of the goals of this site is to contain links to every VSX-related useful piece of information out there, I have added in the Articles section about packages some old (2009-2010) blogs posts about VSIX and Pkgdef files. They are still relevant today and are the following:

Moving from add-ins to packages, VS Packages

Targeting multiple Visual Studio versions with the same binary package assembly

2 Comments

I am these days porting my MZ-Tools add-in to a package, and as every other developer of extensions I would like to target several different Visual Studio versions (say 2010, 2012 and 2013 and “14”) with:

  1. The same project file (MyAssembly.csproj)
  2. The same binary assembly (MyAssembly.dll)
  3. The same setup (MyAssembly.vsix or MyAssemblySetup.exe)

About #1, you need to learn something about MSBuild but is doable. In my case I just want to use VS 2013 always and changing something in the .csproj file I can deploy and debug selectively to VS 2010, 2012 or 2013 experimental instances. But if you want to change nothing, you can open the same .csproj file in different VS versions and deploy and debug for that VS version as Daniel Cazzulino explained in his post How to create a Visual Studio extensibility project that is compatible with VS 2010, 2012 and 2013. Jared Parsons has also explained about Round Tripping a VSIX project.

About #2, if you stick to the assemblies provided by VS 2010 that are also supplied by higher VS versions it is doable too. I have used that approach for MZ-Tools being an add-in for years, as I explained in the article HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET.

About #3, .vsix files already have support for several Visual Studio versions specified in the manifest. And if you create your own setup (MSI or otherwise) you have full control of the deployment.

Moving from add-ins to packages, VS Packages

Forcing Command UI refresh

As you know, whether you are an add-in developer or a package developer, Visual Studio calls your package or add-in to query the status of your commands when it requires to know it, for example, before showing the menu items of a menu, when the selected object has changed, etc. However, in rare occasions you may need to tell Visual Studio that you want it to query the status of your commands. A user of the MSDN VSX forum has asked it today, for example.

I was somewhat familiar with the solution for add-ins, which is to use the UpdateCommandUI method of the EnvDTE80.Commands2 interface (notice that the EnvDTE.Commands interface lacks that method, so you need to cast DTE.Commands to EnvDTE80.Commands2). Reviewing the code of my MZ-Tools add-in, certainly I needed to use it for a integration test.

I was also somewhat familiar with the solution for packages because I found the UpdateCommandUI method of the IVsUIShell by chance some time ago just perusing the MSDN documentation.

Moving from add-ins to packages, MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: PRB: Button of package command cannot be initially invisible on Visual Studio toolbar

While migrating my MZ-Tools add-in to a package, I found an issue: I wanted a button to be initially invisible on my toolbar. By “initially” I mean before the package is loaded, that is, declaring the invisibility in the .vsct file using:

<CommandFlag>DynamicVisibility</CommandFlag>
<CommandFlag>DefaultInvisible</CommandFlag>

However, the button appeared initially disabled rather than invisible. Investigating I found this reported in the MSDN VSX forum as back as in 2006 (VS 2005 I guess) using the old .ctc file rather than the new .vsct file and, guess what, that behavior is “by design”. However, buttons on toolwindows toolbars (rather that on IDE toolbars) can be initially invisible.

I created a sample package to reproduce the problem. The package creates two commands (the first one initially invisible) that are placed in three locations: the Tools menu, the Standard toolbar and the Solution Explorer toolbar. Notice that the button on the Standard toolbar is disabled rather than invisible:

PackageCommandButtonNotInvisibleOnVSToolbar

And I have documented this behavior with code in this article:

PRB: Button of package command cannot be initially invisible on Visual Studio toolbar

Moving from add-ins to packages, MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: INFO: How a Visual Studio package command is named

Another very confusing thing when starting with packages and you have a background of creating add-ins is how to name a command.

With add-ins, the (full) name of a command was composed by two parts:

And one interesting consequence was that all the commands of your add-in used the same prefix. With packages this is not true. The prefix of a command created by a package follows some complicated rules that depend on the menu / toolbar / context menu where the command is mainly placed (because, you know, a command is not a UI item and you can create several UI items in different locations tied to the same command).

And even the (short) name of the command can vary depending on the values of <CommandName>, <LocCanonicalName> and, go figure, can even be inferred from the caption of the command (<ButtonText>) removing special characters, etc.

I have written this article to try to explain all rules:

INFO: How a Visual Studio package command is named

Moving from add-ins to packages, MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: HOWTO: Create a command without user interface items from a Visual Studio package.

One of the most confusing things when starting with packages and you have a background of creating add-ins is how to create and name commands, which are not user interface items.

With add-ins, commands are created by code, and there are two separate steps: one to create the command (Commands2.AddNamedCommand2 method) and other step to create UI items (either temporary or permanent) such as menu items, toolbar buttons, etc. See:

HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in.

However, commands in packages are created by declarations in a .vsct file, and the separation between command and UI items is very blurry (and how to name a command is a subject for another post). For example, you have a <Commands> section, but commands are actually declared inside a <Buttons> section using <Button> elements. I can’t insist enough that in Visual Studio a command is not a button (or a menu item), and, in fact, sometimes your extension may want to provide a command without a user interface item. For example, if you want the command to be executed by default only with a keyboard shortcut. Or for some reason you need an “internal” command. My MZ-Tools add-in does this with at least one command.

So, I have written this article to show how you would create a command in a package without UI items:

HOWTO: Create a command without user interface items from a Visual Studio package

Moving from add-ins to packages, MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: HOWTO: Execute a command by Guid and Id from a Visual Studio package

There are a few articles / samples that I wrote in July but I forgot to blog about because I have been busy tuning this new web site and also I was a couple of weeks on vacation. This is the first of them.

Some years ago I wrote about executing a command by Guid and Id (rather than by name) from a VS add-in:

HOWTO: Execute a command by Guid and Id from a Visual Studio add-in
http://www.mztools.com/articles/2008/MZ2008013.aspx

As part of my strategy to moving from add-in to package for my MZ-Tools add-in, I want to get rid of EnvDTE as much as possible, so this is the equivalent using an automation-free approach to do the same:

HOWTO: Execute a command by Guid and Id from a Visual Studio package
http://www.mztools.com/articles/2014/MZ2014018.aspx

MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: HOWTO: Write to the output window panes from a Visual Studio package.

Today I am writing the equivalent of this article for add-ins that I wrote originally almost 6 years ago:

HOWTO: Get an OutputWindowPane to output some string from a Visual Studio add-in or macro
http://www.mztools.com/articles/2008/MZ2008023.aspx

but in this case natively (using services) for Visual Studio packages:

HOWTO: Write to the output window panes from a Visual Studio package.
http://www.mztools.com/articles/2014/MZ2014017.aspx

MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: HOWTO: Initialize the usercontrol of a toolwindow from a Visual Studio package.

Although creating a toolwindow and hosting a usercontrol in a Visual Studio package seems easy (thanks to the package wizard), initializing the usercontrol to receive an instance of your package (or the value of some property of your package) is somewhat tricky.

I have seen this question from time to time in the forums and until now my (wrong) answer was to use the ShowToolWindow event handler method of the package to get the instance of the usercontrol from the ToolWindowPane (using its Content property for WPF usercontrols and its Window property for Windows Forms usercontrols). Once you have the usercontrol instance, you can call a method of the usercontrol to pass it any piece of information that you want to initialize it. I won’t show the code because it is an incorrect approach due to this: when using a toolwindow in a package, if the last time that you closed Visual Studio the toolwindow was visible, the next time that you open Visual Studio the toolwindow will be shown automatically without the ShowToolWindow event handler method being called (so your usercontrol wouldn’t be initialized in that scenario).

This didn’t happen with add-ins (toolwindows were not open automatically in the next session if left open in the previous session). But with packages it happens, so the ShowToolWindow method of the package is not the proper place to initialize the usercontrol. Then, it must be done in the MyToolWindow class, which creates the usercontrol and it is always called, and fortunately it has a Package base property that you can use to get the instance of your package. Alas, that instance is null in the toolwindow constructor. My latest article shows a workaround:

HOWTO: Initialize the usercontrol of a toolwindow from a Visual Studio package
http://www.mztools.com/articles/2014/MZ2014016.aspx

MZ-Tools Articles Series, VS Packages

MZ-Tools Articles Series: HOWTO: Host a Windows Forms usercontrol in a toolwindow from a Visual Studio package.

When you create a toolwindow with the Visual Studio package wizard, a Windows Presentation Foundation (WPF) usercontrol is used. If you are migrating an add-in to a package, chances are that your toolwindows use Windows Form usercontrols and you don’t want to change the forms technology (migrating the add-in to a package is enough work…). It happens that the way to host a usercontrol in a toolwindow is different for WPF and Windows Forms. In the former case you only have to assign the Content property to the instance of the usercontrol. If you do the same in the latter case, nothing happens (you don’t even get an exception). For Windows Forms usercontrols, you need to override the Window property to return the instance of the usercontrol.

My latest article explain it with sample code:

HOWTO: Host a Windows Forms usercontrol in a toolwindow from a Visual Studio package.
http://www.mztools.com/articles/2014/MZ2014015.aspx