The issue that I opened about VS 2010 Beta 1 command pictures supporting for the first time 32-bit bitmaps with alpha channel for transparency but not RGB=0,254,0 as in previous Visual Studio versions has been resolved by Microsoft for Beta 2:

Custom pictures in CommandBarButtons created by add-in don’t show a transparent background
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=461192

So, while we’ll have to wait until we get the VS 2010 Beta 2 bits to test all this, Microsoft seems to have solved in a very acceptable way the nightmares of bitmap transparency for add-ins:

• Command pictures will support 32-bit bitmaps with alpha channel (new way, first time) or RGB=0,254,0 for transparent color (old way)
• Toolwindow pictures will support 32-bit bitmaps with alpha channel or RGB=255,0,255 for transparent color (old way).

Bottom line:

• If your add-in only targets VS 2010 you can use 32-bit bitmaps with alpha channel for everything and forget about old hacks. While it seems that icons will not be supported (a long-time request from me) you can use transparent bitmaps.
• If you have to support VS 2005/2008 yet, you can still use the old hacks (some special RGB color) in VS 2010 and keep a single bitmap set.

Now, if we could get rid of satellite DLLs…

Although VS 2010 Beta 2 hasn’t been released yet, Microsoft has stopped fixing the certainly minor bugs that I have reported in the last days about the C# file code model. Instead they are currently focused “on stabilizing and improving the performance of VS2010”. This is something that has happened in the past (I remember since VS 2005): once the Beta 2 is released no feature is changed and very few bugs are fixed (only the big ones that would prevent the release of the product), but I think that this time is worse, the facts are:

• VS 2010 Beta 1 was not feature completed (the customization of toolbars was disabled for Beta 1, for example)
• It had important bugs in the new WPF commandbar model
• VS 2010 Beta 2 is not released yet, but some bugs won’t be fixed until VS 11 !

Too bad. I’m talking about minor bugs that should be easy to fix, not ones requiring architectural changes that I understand will be postponed.

I find quite stressing what will happen if the WPF commandbars are not fixed correctly for Beta 2, or new bugs appear with features that were not completed in Beta 1. I’d rather see no CTPs at all and a longer series of betas instead:

• Beta 1: quite feature completed. Time to complete it and fix bugs.
• Beta 2: feature completed. Time to fix bugs.
• Beta 3: bugs fixed. Time to focus on stabilization and performance.
• RC1, etc.

At least we would have two beta cycles to get bugs fixed.

All that said, I welcome the focus on the performance of the Visual Studio (the 2005 release was quite bad in this regard).

UPDATE: Microsoft clarified that this affects only to bugs in the code model because they are investing in a new code model. See Clarification on my previous post “Microsoft no longer fixing (small) bugs for VS 2010”

The little problem that I reported when using the SetTabPicture method with a 32-bit bitmap with alpha channel for transparency has been fixed according to the last notification from Microsoft for the following VS 2010 beta build:

EnvDTE.Window.SetTabPicture doesn’t support 32-bit bitmaps with transparency in alpha channel when toolwindow not active
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=470236

That means that for the first time a Visual Studio version (2010) will support 32-bit bitmap with alpha channel for transparency both for add-in command pictures (EnvDTE.DTE.AddNamedCommand) and toolwindow pictures (EnvDTE.Window.SetTabPicture), and you can get rid of magenta (RGB=255,0,255) and almost green (RGB=0,254,0) hacks in add-ins, which is really great and very close to the support for icons with built-in transparency that I have been battling for all these years. I don’t care if I have to use 32-bit bitmaps with alpha channel instead of icons. It is also great because in most cases the toolwindow picture is the same than the picture of the command that shows the toolwindow, so you can use the same picture without re-colorizing the background from green to magenta or transparent when calling SetTabPicture, or providing two versions of the same picture with different backgrounds.

The only problem is if you still have to support old versions of Visual Studio (2005, 2008) which I guess will be the case for most commercial add-ins because VS 2010 doesn’t support the RGB=0,254,0 color for command picture transparency that was used in those versions, this issue is still active at the time of this writing (Update (August 6): VS 2010 Beta 2 will support RGB=0,254,0 too for backwards compatibility):

Custom pictures in CommandBarButtons created by add-in don’t show a transparent background
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=461192

In the previous post I explained how to get transparent bitmaps for add-in commands in VS 2010 Beta 1 and previous versions. Now it is the turn of toolwindow bitmaps. Again, if you have a .NET 2.0 add-in that uses XML registration and a managed
satellite DLL and targets VS 2005, 2008 and 2010 Beta 1, the situation is as
follows:

1) Toolwindow bitmaps for VS 2005:

• Use either:
  • A 32-bit bitmap with transparency in the alpha channel.
  • A 24-bit bitmap with RGB=255,0,255 (magenta) as transparent color
• Call EnvDTE.Window.SetTabPicture(bitmap.GetHbitmap) (for some reason passing bitmap.GetHbitmap().ToInt32 causes System.ArgumentException: Value does not fall within the expected range)
• Call EnvDTE.Window.Visible = True (this must be done after setting the toolwindow picture)

2) Toolwindow bitmaps for VS 2008:

• Use either:
  • A 32-bit bitmap with transparency in the alpha channel.
  • If the color depth of the screen is:
    • 16-bit, you can use a 24-bit bitmap with RGB=0,254,0 (almost pure green) or a 24-bit bitmap with RGB=255,0,255 (magenta) as transparent color
    • 24-bit: I couldn’t test this case on my computers.
    • 32-bit: you need to make the bitmap transparent calling bitmap.MakeTransparent(<background color>).
• Call EnvDTE.Window.SetTabPicture(bitmap.GetHbitmap().ToInt32()) (for some reason passing just bitmap.GetHbitmap causes System.ArgumentException. You need to convert the IntPtr to integer)
• Call EnvDTE.Window.Visible = True (this must be done after setting the toolwindow picture)

3) Toolwindow bitmaps for VS 2010 Beta 1:

• Use either:
  • A 32-bit bitmap with transparency in the alpha channel. Due to a bug that I have already reported, in this case the toolwindow picture shows transparency when focused, but doesn’t when not focused
  • A 24-bit bitmap with RGB=0,254,0 (almost pure green) as transparent color
  • A 24-bit bitmap with RGB=255,0,255 (magenta) as transparent color
• Call either EnvDTE.Window.SetTabPicture(bitmap.GetHbitmap()) or EnvDTE.Window.SetTabPicture(bitmap.GetHbitmap().ToInt32())
• Call EnvDTE.Window.Visible = True (this must be done after setting the toolwindow picture)

Bottom line: if the bug mentioned above with VS 2010 and 32-bit bitmap with transparency in the alpha channel is fixed for VS 2010 final release (Update, August 6: VS 2010 Beta 2 will fix it), you will be able to use 32-bit bitmap with transparency in the alpha channel in the three VS versions, but taking into account that sometimes you need to use the IntPtr value returned by GetHBitmap, and others its Int32 value.

I hope the information above is accurate because it is really messing to test all cases. Let me know if you can corroborate or not.

After my rant of yesterday about Bitmap transparency nightmares at Microsoft too I have continued today with my testings and finally I got transparent bitmaps in commands of add-ins for VS 2010 Beta 1. If you have a .NET 2.0 add-in that uses XML registration and a managed satellite DLL and targets VS 2005, 2008 and 2010, the situation is as follows:

1) Command bitmaps for VS 2005 and VS 2008:

• They need to use RGB=0,254,0 (almost pure green) as transparent color. This has been so since VS.NET 2002.
• They do not support 32-bit bitmaps (which support built-in transparency through the alpha channel). You get white background instead.

2) Command bitmaps for VS 2010 Beta 1:

• They do not use RGB=0,254,0 (almost pure green) as transparent color. You get a green background instead. This is a lack of backwards compatibility that I reported some weeks ago through Microsoft Connect. At the time of this writing, the bug is under investigation but it might well be closed as “by design” because it seems that Microsoft is finally solving the problem for good supporting built-in transparency with 32-bit bitmaps and removing old hacks such as magenta or green background as their own user interface guidelines suggest. Update (August 5): the last feedback from MS in the Microsoft Connect bug report indicates that RGB=0,254,0 will be supported also in VS 2010 Beta 2. Great news!
• They do support 32-bit bitmaps (which support built-in transparency through the alpha channel). Support for 32-bit bitmaps in add-in commands is something new that didn’t work in previous versions of Visual Studio.

Bottom line: if nothing changes from Beta 1 to final release, your satellite managed Dll will need to include two sets of bitmaps: ones with 24-bit and RGB=0,254,0 background for VS 2005/2008 and other with 32-bit bitmaps with transparency in alpha channel for VS 2010.  This is so because you don’t have any chance of manipulating the bitmap in your code when suplying bitmaps Ids to the AddNamedCommand method, on the contrary to the Window.SetTabPicture method of toolwindows (which will be the subject of another future post).

While it would be good to support the old way too a couple of VS releases, I don’t care suplying two sets of bitmaps because finally this is going in the good direction, that is, built-in transparency without magic tricks. See update above.

There is a little problem though: it can be tricky to get an editor that support 32-bit bitmaps correctly. First, some editors allow “4-bit”, “8-bit”, and “True Color” bitmaps, where it is not clear if “True Color” means 24-bit or 32-bit (with alpha channel). Most of the time it means 24-bit, though. Second, some editors don’t support 32-bit bitmaps at all: forget MS Paint and others such as the Visual Studio bitmap editor (it seems). For this purpose I have used the wonderful Axialis IconWorkshop icon editor. Other modern icon editors may work too. The procedure is the following:

• Create a 16×16 icon with RGB/Alpha Channel (RGB/A – 32 bits) depth color
• Draw your icon leaving the transparent background
• Click FileExport…Bitmap Image. When prompted, select “Preserve Transparency information (saved to 32 bpp)”.

Now, if the add-in could supply the bitmaps in its own Dll rather than in a satellite Dll…

A week ago I blogged about some nasty bugs that happened in VS 2010 Beta 1 when using the new WPF-based commandbars from an add-in. While VS 2010 Beta 1 was very disappointing for me in this regard, the response from Microsoft in the last days has been great and so far the following ones 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

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

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

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

These others are still active (I hope they are fixed too) but are not so critical or have workarounds:

System.ArgumentNullException: “Value cannot be null.” getting CommandBar.Position from an add-in
Workaround: since it seems that VS 2010 toolbars can’t be moved by hand by the user, it is not much needed to use this property

CommandBars.Item(“Tools”) causes exception rather than finding the commandbar.
Workaround: HOWTO: Locate commandbars in international versions of Visual Studio

CommandBarButton.TooltipText causes exceptions when getting or setting its value
Workaround: use the tooltip parameter of the AddNamedCommand method rather than this property.

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.

As you likely know when reading this, Microsoft has released the Beta 1 of Visual Studio 2010. This release introduces a lot of internal and external changes, such as a WPF-based shell, a new WPF-based editor, and a new extension manager, etc. and therefore a lot of issues will arise with existing or new extensions (I certainly have a few of them regarding add-ins that I will blog in the next days).

You can report feedback to Microsoft about this release regarding extensibility using a couple of ways:

The Microsoft Connect web site:
https://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=12362

The new VS 2010 Beta 1 Extensibility Forum:
http://social.msdn.microsoft.com/Forums/en-US/vsxprerelease/threads