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:

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

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

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:

• A prefix that was the ProgId (VS.NET 2002/2003) or namespace (VS 2005 and higher) of the Connect class. See: HOWTO: Create command names without ‘.Connect’ in Visual Studio add-ins
• The actual (short) name of the command, which was explicitly set when you create the command with the Commands2.AddNamedCommand2 method.

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

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

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