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.
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:
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:
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
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
The Community Technology Preview (CTP) 3 of Visual Studio “14″ released today that you can download as web package or iso package, or as Windows Azure virtual machine , introduces “high resolution icons in command bars, tool window toolbars (standard), and main menus when it is running greater than 100% DPI scaling”, according to the release notes.
This likely means that extensions should also provide high resolution images. Providing images for buttons and menus has always been tricky for add-ins due to transparency issues, magic colors (almost green, magenta, etc.), satellite dlls, etc. Fortunately VS 2010 solved most problems, only for VS 2012 to complicate things again with the dark theme and inverted colors.
I haven’t had the chance of playing with VS “14″, only to check that add-ins are gone, so packages are the only extensions that must provide those high resolution icons.
Once again an update of the following article was due to include the latest project type Guids introduced by Visual Studio 2013:
INFO: List of known project type Guids
As always, feel free to contact me if you want to include a missing one.
If you are a long-time developer of Visual Studio extensions (add-ins, packages, etc.) chances are that you are tired of telling your users that your extension won’t work on the Express Editions of Visual Studio.
And if you still think that it should work because Microsoft’s extensions work, repeat after me:
“Visual Studio Express edition doesn’t support extensions
Visual Studio Express edition doesn’t support extensions
Visual Studio Express edition doesn’t support extensions
I explained it more elaborated in this other post: Visual Studio Express edition doesn’t support extensions (despite its Extension Manager).
Now, if you want to change this, you can tell Microsoft voting on the two UserVoice requests that are open:
Allow 3rd party Extensions (vsix) in Visual Studio Express editions
Allow extensions/plugins for VS Express
After the old blog server of MVPs at msmvps.com (using Community Server) died some days ago (mine was http://msmvps.com/blogs/carlosq/), the administrator created a new one using WordPress (http://blogs.msmvps.com/carlosq/). It happened that in the meantime I purchased this domain http://www.visualstudioextensibility.com/ and WordPress hosting with two goals:
- To create a super portal about Visual Studio Extensibility (VSX) that not only contains my blog but also pages with all the resources available on the web about VSX.
- To have total control of my blog, something that I didn’t have with my old blog, and I didn’t have with the new one either.
So, this is my new home.
Please update your RSS feed subscription to:
And now I have also a Twitter account:
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
but in this case natively (using services) for Visual Studio packages:
HOWTO: Write to the output window panes from a Visual Studio package.