Known bugs in the new CommandBars of VS 2010 Beta 1

VS 2010 is changing the commandbars from the COM-based ones borrowed from Office to new WPF (.NET) ones, and the Beta 1 is the first public release showing this. The change is still under construction. For example, the “Tools”, “Customize…” menu is disabled for Beta 1 and you can’t change by hand (you can programmatically) a toolbar location from the top to the bottom, or to the left/right or make it floating as in previous versions. I am not sure if this is “by design” or a “not implemented yet” feature.

There are good news and bad news regarding the new CommandBar implementation.

The good news are that:

– Finally we may get rid of obscure COMExceptions that happened from time to time in the old implementation that I reported here, here and here.

– The object model is the same to to preserve compatibility with existing add-ins.

The bad news are:

– The object model is the same, confusing one, with lots of optional parameters, Object-typed parameters and so on. This is to preserve compatibility with existing add-ins, but there is not a new more clear model with strongly typed parameters and more intuitive. You can learn the model here: HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in

– The object model is not 100% backwards at run-time, some properties cause a “deprecated exception”. Not a big deal, but something to take into account.

– The new model still requires a satellite DLL and doesn’t accept icons yet to support transparency on custom buttons more easily, and guess what, you can’t get transparent buttons on Beta 1 (at least using a native resource dll, I have to test with a managed satellite DLL). I am strongly discussing this with Microsoft to see if they can fix this problem for good.

– There are quite a few bugs yet (some others that I reported were fixed for Beta 1). My list of known bugs is the following one, just in case you want to be aware of them or want to vote to get them fixed:

These ones are already acknowledged and will be fixed in the next build:

CommandBarButtons created by add-ins in context menus don’t appear

CommandBarPopup on toolbars doesn’t show arrow to indicate the dropdown

These ones are being investigated at the time of this writing:

Custom pictures in CommandBarButtons created by add-in don’t show a transparent background

EnvDTE.Command.Delete does not remove CommandBarButtons created from that command on Visual Studio commandbars

System.ArgumentNullException: “Value cannot be null.” getting CommandBar.Position from an add-in

“Object must be the same type as the enum” exception calling CommandBars.Add from an add-in

CommandBars.Item(“Tools”) causes exception rather than finding the commandbar.

CommandBarButton.TooltipText causes exceptions when getting or setting its value

Hopefully we can get them fixed, I have spent a lot of time this week isolating them to the minimal expression (my MZ-Tools add-in has a complex architecture to handle commands and buttons).

Interesting, challenging times regarding Visual Studio extensibility

If you have read about and played with Visual Studio 2010 Beta 1, you will have notice that we are under a major change, not so breaking in the external shell but internally. Visual Studio was born as a native, COM-based, C++ application and it seems that it has started a journey of several years towards a managed, .NET application. For the end user, the changes are not so huge: a more nice look and feel in commandbars, toolwindows or editor windows, a new extension manager to discover and install extensions, etc. but for developers extending Visual Studio, although in the long term this will be great, in the short term this is kind of a nightmare because of:

  • As it happens with new development, it will be plagued with bugs until all of them are fixed.
  • Some things are being “deprecated”. Have you noticed the “DeprecatedException” when using properties of the new CommandBars, CommandBarButtons, etc?
  • At the very least, you must test completely your extension (add-in, package) to see if it works with VS 2010, and either report bugs to MS or find workarounds to make it work.
  • You need to think carefully whether or how to leverage new extensibility features of VS, or keep using a common denominator. That is, for end-users it is great all the new improvements in each VS iteration, but as a developer of commercial or public extensions, you need to target many versions of VS. For example: do you use an common extension with .NET 2.0 for VS 2005, 2008 and 2010? Or do you create a separate version for VS 2010, maybe with .NET 4.0? Do you use the same setup for all? Or do you leverage the new Extension Manager for VS 2010?
  • Since add-ins are starting to be second-class citizens (with few development of new classes, methods and properties in EnvDTE* assemblies and missing or contradicting information about support in the new Extension Manager), do I start migrating to a package? Is it sensible to do it now when VS.NET 2003 should be still supported? Do I wait some years when package development (SDK) is truly easy?

When a type name is not the same that the same type name

Playing with Visual Studio 2010 Beta 1 and executing this statement:

toolBar = commandBars.Add(Name:=”My toolbar”, Position:=Microsoft.VisualStudio.CommandBars.MsoBarPosition.msoBarTop, Temporary:=True)

I have encountered this funny error:

“Object must be the same type as the enum. The type passed in was ‘Microsoft.VisualStudio.CommandBars.MsoBarPosition’; the enum type was ‘Microsoft.VisualStudio.CommandBars.MsoBarPosition’.”

What I guess that the error message is trying to say is that it was expecting a parameter with the type


and it received a parameter with the type


Since the type names are the same, why is it complaining?

I recalled that this is not the first time that I see this situation. The other one was the error “[found ref ‘EnvDTE.ProjectItem’][expected ref ‘EnvDTE.ProjectItem’] Unexpected type on the stack.” when using peverify.exe.

When this happens (the expected type name and the actual type name are the same but there is an error yet), it is because the types come from assemblies that are not the same. The assemblies may even have the same name, but they were loaded from different locations, and therefore are different instances and are different “things”.

In the case of the Microsoft.VisualStudio.CommandBars.MsoBarPosition, the problem happens because .NET 4.0 introduces a new feature named “No PIA – Primary Interop Assembly” which works embedding the actual used declarations of an (ActiveX) Interop reference in the assembly being built, so that the referenced PIA assembly doesn’t need to be deployed. And it happens that the add-in wizard creates a reference to Microsoft.VisualStudio.CommandBars.dll with the “Embed Interop Types” property set to True. Once compiled, the embedded types in the add-in assembly are not the same that those in the Microsoft.VisualStudio.CommandBars.dll PIA, and it seems that the commandBars.Add method (which receives Object types as parameters) do some checks about the passed types that fail unless you set the “Embed Interop Types” property to False.

You can vote to get this bug fixed here:

Visual Studio 2010 Beta 1 too slow on Virtual PC

I have spent the last days testing my MZ-Tools add-in with Visual Studio 2010 Beta 1 and there are a couple of things that I have noticed: the second one is that Beta 1 breaks a lot of things in the commandbars (I am reporting all the issues to Microsoft through Microsoft Connect and I will blog about the problems in the next days/weeks), but the first one is that Virtual PC 2007 (version is too slow, painfully slow to debug add-ins. I am using Windows XP on a modern (desktop) computer (Core 2 Duo E8400, 3 GHz, 4 GB RAM) and I have assigned 2 GB to the virtual machine but the thing is so slow that on a second (laptop) computer at home I gave up and I created a second partition on the hard disk, which I also used to play with Windows 7 RC and it seems that it runs much better.

I have never been very fan about Virtual PC since I used it to test VS 2008 “Orcas” a couple of years ago and found some problems. Considering that Visual Studio is a monster in terms of performance (I know this is an early beta, but nonetheless), that today’s hard disks have enough space for another partition that you can even create within Windows without 3rd party tools, and that installing Windows takes less than an hour, I much prefer dual boot to test VS 2010 betas than Virtual PC.