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).

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

‘Microsoft.VisualStudio.CommandBars.MsoBarPosition’

and it received a parameter with the type

‘Microsoft.VisualStudio.CommandBars.MsoBarPosition’

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:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=462766

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 6.0.156.0) 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.