VS 2010

Solved: transparent bitmaps in add-in commands of VS 2010 (Beta 1)

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…