FWIW, I have verified that VS 2010 Beta 2 certainly fixes the issue of supporting RGB=0,254,0 for transparent color in 24-bit command pictures that I mentioned here.

So, if your add-in targets VS 2005, 2008 and 2010 you can use that color for the transparent background color of command pictures and they won’t appear with lime green in Beta 2 as it happened in Beta 1 or previous CTPs builds.

If your add-in only targets VS 2010 it is preferable to use the new support for 32-bit command bitmaps. I guess that in a few years Microsoft will only support 32-bit bitmaps in Visual Studio.

This is going to be messy, so step by step:

Imagine that you are developing an add-in that uses a temporary user interface (not permanent one), and creates a couple of commandbars of kind “toolbar”, and many commandbars of kind “popup” (with submenus).

Since it uses a temporary user interface, it must delete those commandbars when unloaded.

For that purpose, it must keep a reference to each created commandbar at class level (all this is explained in the article of the previous link).

Since it creates lots of commandbars, rather than keeping each one individually, they are stored in a class-level collection. Of which type?

CommandBars of kind “Toolbar” have the “Microsoft.VisualStudio.CommandBars.CommandBar” type but commandbars of kind “popup” have the Microsoft.VisualStudio.CommandBars.CommandBarPopup” type, so both can’t be stored in the same typed collection, but we would like to use a single collection, not two, or not a collection of System.Object.

Fortunately the Microsoft.VisualStudio.CommandBars.CommandBarPopup type has a CommandBar property, and since the Microsoft.VisualStudio.CommandBars.CommandBar type has a Parent property (typed as System.Object, that should return a Microsoft.VisualStudio.CommandBars.CommandBarPopup actually), you can use a generic typed collection List<Microsoft.VisualStudio.CommandBars.CommandBar>, which stores the CommandBar of toolbars, and the CommandBarPopup.CommandBar of popup commandbars.

When the add-in is unloaded, it iterates the commandbars of the collection to delete them:

• If the CommandBar.Type is MsoBarType.msoBarTypeNormal, the commandbar is a toolbar and can be deleted calling the Delete method.
• If the CommandBar.Type is MsoBarType.msoBarTypePopup, the commandbar is a popup so we get its Parent property (which is a System.Object) and we cast it to Microsoft.VisualStudio.CommandBars.CommandBarPopup. Then, we call the Delete method of CommandBarPopup.

(As I mentioned, my MZ-Tools add-ins seems to use every conceivable technique provided by the Microsoft.VisualStudio.CommandBars API)

However, this approach that worked perfectly in VS 2005/2008, doesn’t work in VS 2010. Why?

It happens that VS 2010 uses WPF-based commandbars, but add-ins for VS 2010 still use the Microsoft.VisualStudio.CommandBars Interop (ActiveX) assembly for backwards compatibility.

That interop assembly provides the Microsoft.VisualStudio.CommandBars.CommandBarPopup type, which is actually an interface (although it doesn’t follow the convention for interface names), not a class. The same happens with the CommandBar and CommandBarControl types, which are interfaces, not classes. The CommandBarButton type is a class, though. To complicate things, you have the CommandBars class and the _CommandBars interface… anyway:

In VS 2005/2008, which use native (COM) commandbars, the classes that actually implement those interfaces are native, and from a managed add-in you see them through a System.__ComObject which is the Runtime Callable Wrapper (RCW) that you get when you don’t have an interop assembly. But since they implement the interfaces provided by the Microsoft.VisualStudio.CommandBars assembly, the add-in works fine.

In VS 2010, which uses managed (.NET) WPF commandbars, the classes that actually implement those interfaces are managed and are provided by the Microsoft.VisualStudio.PlatformUI.Automation namespace in the managed (.NET) Microsoft.VisualStudio.Shell.UI.Internal.dll assembly (in one of the VS 2010 folders).

When you create a commandbar popup calling:

Microsoft.VisualStudio.CommandBars.CommandBarControl commandBarControl;
commandBarControl = parentCommandBar.Controls.Add(MsoControlType.msoControlPopup);

you get some class instance that implements the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface. So you can do this cast:

Microsoft.VisualStudio.CommandBars.CommandBarPopup commandBarPopup;
commandBarPopup = (Microsoft.VisualStudio.CommandBars.CommandBarPopup) commandBarControl;

In VS 2010, the actual class that implements that Microsoft.VisualStudio.CommandBars.CommandBarPopup interface is the Microsoft.VisualStudio.PlatformUI.Automation.CommandBarPopup._Marshaler class.

However, when you do this:

commandBarPopup.CommandBar.Parent

in VS 2005/2008 you get an object that implements the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface (as expected), so the approach described in the beginning of this post worked.

In VS 2010 you get an instance of the Microsoft.VisualStudio.PlatformUI.Automation.CommandBarPopup class, not of the Microsoft.VisualStudio.PlatformUI.Automation.CommandBarPopup._Marshaler class that you got when creating it.

It happens that the Microsoft.VisualStudio.PlatformUI.Automation.CommandBarPopup class doesn’t implement the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface. It implements IMarshaledObject<CommandBarPopup> instead. It also has a Marshaller property that would return the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface implementation.

So, the approach that worked with VS 2005/2008 doesn’t work with VS 2010.

Since you can’t cast or get the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface and an add-in targeting VS 2005/2008/2010 with the same dll can’t include a reference to the Microsoft.VisualStudio.Shell.UI.Internal.dll, keeping this approach the only way would be to call its Delete method would be through Reflection.

If you are testing your add-in with the recently released VS 2010 Beta 2 chances are that you have noticed that the new WPF-based commandbars, buttons and icons are not yet ready for prime time. It seems that my MZ-Tools add-in uses every possible method, property and technique offered by the Microsoft.VisualStudio.CommandBars API so I am discovering lots of bugs (I have reported 15 so far) since I started testing with Beta 1. I reported these two ones before Beta 2 but the fixed will come in builds after Beta 2:

VS 2010 Beta 2 Bug: System.AccessViolationException attempting to create a temporary popup commandbar
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=500408

VS 2010 Beta 2 Bug: CommandBarButton.Style not honored, always Icon + Caption
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=500403

If you are developing add-ins for in-house use, chances are that you can drive, encourage or even force the whole organization to use the latest version of Visual Studio and therefore your add-in needs to target only that version. But if you are developing add-ins for commercial or open-source purposes, to be used by lots of people, your add-in needs to target several IDE versions (nowadays, at the very least VS 2005, 2008 and 2010). To simplify your life as a developer, you try to keep a single code base and a single binary dll. For example:

• You create the add-in with VS 2005 (and therefore .NET Framework 2.0 / CLR 2.0) with a single project, referencing EnvDTE and EnvDTE80, VSLangProj, VSLangProj2 and VSLangProj80, generate a single DLL, but you create the proper .AddIn file and put it in the proper folder to target VS 2008 too.

or:

• You create the add-in with VS 2008 (targeting .NET Framewor 2.0 / CLR 2.0) with a single project, with the same references than above, taking care of not referencing EnvDTE90 or VSLangProj90 (which are specific to VS 2008), generate a single DLL, but you create the proper .AddIn file and put in in the proper folder to target VS 2005 too.

Both approaches work. Some people use the first one to ensure 100% that the add-in will work with VS 2005 (since it was created with that IDE and .NET Framework 2.0) although I personally use the second one (I like VS 2008 much more than VS 2005) with no problems so far.

If for some reason the add-in needs to know the IDE version where is hosted or behave differently dynamically depending on the IDE version, it can guess it using DTE.Version or DTE.RegistryRoot, but there is no need to have separate DLLs if both VS 2005 and VS 2008 can use the same CLR 2.0, .NET Framework 2.0 and the same set of references.

Now, VS 2010 comes. So, your natural approach is to keep your existing code, binary dll and make it target VS 2010 adjusting the .AddIn file. Although VS 2010 uses a new CLR (4.0) instead of CLR 2.0, a CLR can load assemblies compiled against the previous version, in the same way that VS.NET 2003 (using CLR 1.1) could use add-ins created with VS.NET 2002 (using CLR 1.0) if the add-in was properly registered.

When you create your add-in with VS 2005 and you want to debug it on VS 2008, you just simply go to the Debug tab of the project properties and set the Start Action to start the devenv.exe of VS 2008, and this works perfectly.

Similarly, when you create your add-in with VS 2008 and you want to debug it on VS 2010, this worked perfectly until VS 2010 Beta 2. With the Beta 2 released two days ago you get the error:

The debugger’s protocol is incompatible with the debuggee

I have confirmed with Microsoft that this is not a bug, it is by design: VS 2008 (using CLR 2.0) or VS 2005 won’t be able to debug CLR 2.0 add-ins hosted in VS 2010 (which uses CLR 4.0). Which is a pity, but this means that your workarounds in the scenarios above are:

• Use VS 2010 to create a separate binary add-in DLL (CLR 4.0) for VS 2010 only. For me, this is the worst workaround, only considered as a last resort.
• Use VS 2005/2008 to create a single binary add-in DLL (CLR 2.0) to target VS 2005, 2008 and 2010, giving up debugging on VS 2010, resorting to MessageBoxes in your code to guess what’s going on if you need to debug a problem that can’t be reproduced when the add-in is hosted on VS 2005 or VS 2008.
• Use VS 2010 to create a single binary add-in DLL (targeting CLR 2.0 /  .NET Framework 2.0, not CLR 4.0 / .NET Framework 4.0) to target VS 2005 / 2008 / 2010. I haven’t test this yet but I hope it works. Even if VS 2010 can’t debug a CLR 2.0 add-in hosted on another VS 2010 instance, you can temporarily switch it to target CLR 4.0 and this should work. Once the problem is debugged and solved, you can switch it back to CLR 2.0. I hope that VS 2010 can also debug a CLR 2.0 add-in hosted on VS 2005 or VS 2008.

Let me know if you have more insights about all this.

As you already know from my posts in the last months, VS 2010 will use WPF-based commandbars and will introduce support for 32-bit bitmaps with built-in transparency in the alpha channel for pictures of commands of add-ins, apart from the old way of using 24-bit bitmaps with RGB=0,254,0 for background color. While VS 2010 Beta 1 only supports the new way, I’ve been told that Beta 2 will support the old way for backwards compatibility.

Toolwindows in VS 2005 and higher have always supported either 32-bit bitmaps with built-in transparency in the alpha channel, or 24-bit bitmaps with RGB=255,0,255 as background color, and VS 2010 will support both too.

The third and last area problematic with custom pictures is when you want to set the picture of a CommandBarButton directly (not through a command). While some people use this approach to avoid satellite dlls, the only scenario where I personally use and would recommend this approach is to provide a context menu in some listview or treeview with menu entries that don’t have a command behind (because they are operations for the listview or treeview such as “add”, “edit”, “remove” items, not global operations). To make such context menu with a look & feel 100% consistent with Visual Studio I create a CommandBarPopup. I haven’t written yet an article to show this but the basic idea is to create a commandbar popup calling:

myCommandBarPopup = dte.CommandBars.Add(Name:="MyCommandBar", Position:=MsoBarPosition.msoBarPopup, Temporary:=True)

and then add CommandbarButtons calling:

myCommandBarButton = DirectCast(myCommandBarPopup.Controls.Add(...), CommandBarButton)

and then set the Caption, Picture and Mask properties:

myCommandBarButton.Caption = "..."

myCommandBarButton.Picture = ...

myCommandBarButton.Mask = ...

and then set-up an event handler for the Click event.

Notice that you have to provide a “picture” bitmap, which in VS 2005 and 2008 should be a 24-bit bitmap with any background color, and a “mask” bitmap which should use White=255,255,255 for the pixels that should be transparent color and Black=0,0,0 for the pixels that are actually colored in the “picture” bitmap. Since this has the inconvenience of being forced to provide two bitmaps per button, most people use a custom method to generate the mask image from the picture image.

This is not going to work in VS 2010, though. Since VS 2010 supports 32-bit bitmaps with built-in transparency in the alpha channel, Microsoft is making the CommandBarButton.Mask property deprecated (you get an exception if used). So, if your add-in for VS 2005 / 2008 uses the CommandBarButton.Mask property in one of the two scenarios that I have mentioned, you will need to revisit it and adjust it accordingly to make it work with VS 2010. Assuming that you want the same binary dll to work with VS 2005, 2008 and 2010, one approach is to design 32-bit bitmaps images with built-in transparency (for the VS 2010 version) and generate programmatically the 24-bit “picture” bitmap and the “mask” bitmap for the 2005 and 2008 versions. If your add-in only targets VS 2010, you no longer have to use the CommandBarButton.Picture approach to avoid the satellite dll since VS 2010 will get rid of satellite dlls for add-ins.

The problem that always existed in Visual Studio with the generated grayscale picture for a disabled command of an add-in (or CommandBarButton without a command) is going to be fixed in Visual Studio 2010, according to the tests that I have done. That is, an add-in with a command that provides a 24-bit bitmap in a satellite dll with RGB=0,254,0 as background color (the old way compatible with VS 2005 / 2008) now shows a crisp and defined disabled picture if the command is disabled. Notice that providing a 32-bit bitmap with built-in transparency (the new way introduced in VS 2010) is not required to get this “fix”, it is something that Microsoft has fixed internally even for 24-bit bitmaps in the new WPF-based commandbars of VS 2010.

I have been unable to test if the same applies to CommandBarButtons whose picture is provided through the Picture property (without a command) but I think it will be fixed too.

In my last post Visual Studio 2010 getting rid of satellite DLLs for add-ins I mentioned that VS 2010 will provide two approaches to avoid satellite DLLs for command pictures of add-ins:

The first one was clear: command pictures will be able to be embedded in the own DLL of the add-in.

The second one was not so clear:

“Commands.AddNamedCommand2 will now support an IPicture”.

After that post I exchanged e-mails with Suzanne Hansen (Program Manager of Visual Studio Platform Shell Team) and Jeff Robison (the developer implementing the changes). While I thought that a new EnvDTE100.Commands3.AddNamedCommand3 would be added supporting managed System.Drawing.Bitmap or System.Drawing.Icon types, they explained me that the Bitmap parameter of the current EnvDTE80.Commands2.AddNamedCommand2 method is actually a Variant/Object, not an integer (as it happens with the old EnvDTE.Commands.AddNamedCommand method) and therefore it allows you to pass other types apart from an integer (denoting a numeric bitmap id). Jeff took advantage of this to accept an IPicture type without introducing a new AddNamedCommand method with a different signature.

The bad news was that, alas, IPicture is a native COM type, not a managed type, so developers of managed add-ins would have to use hacks such as OleCreatePictureIndirect or System.Windows.Forms.AxHost.GetIPictureDispFromPicture to convert a managed System.Drawing.Bitmap to a native COM IPicture or IPictureDisp. I was familiar with those techniques (see my article HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands, buttons and toolwindows) and they were ugly to me, and prone to problems with transparency as happened in the past.

So, I suggested to make EnvDTE80.Commands2.AddNamedCommand2 to accept an IntPtr type that would denote the handle of a managed bitmap (System.Drawing.Bitmap.GetHBitmap). The EnvDTE.Window.SetTabPicture already accepts that happily to set the picture of a toolwindow.

They devoted some days to think about all that and a couple of days ago Suzanne informed me that Jeff was able to make EnvDTE80.Commands2.AddNamedCommand2 accept managed System.Drawing.Bitmap or System.Drawing.Icon apart from the native IPicture type added previously. This couldn’t be greater news. Not only you will be able to get rid of embedded bitmaps, so can also use icons if you are not comfortable with 32-bit bitmaps with alpha channel for transparency.

FWIW if you are developing a package and not an add-in:

“Jeff has also made a similar change for package authors – a new API, AddNamedCommand3, will be available that will also accept Bitmaps, Icons and IPictures.”

While these changes won’t be available in the next VS 2010 Beta 2, they will be in subsequent builds. It is also great that they did these changes so late in the VS 2010 development cycle. Usually when Beta 2 is reached it is “feature completed” and no changes such as those are allowed, just bug and performance fixes.

I am looking forward to test these new changes. At last Visual Studio will allow you to decide:

• The way to provide custom pictures for add-ins:
  • Embedded bitmaps in satellite Dll
  • Embedded bitmaps in add-in Dll
  • Directly in the EnvDTE80.Commands2.AddNamedCommand2 method

• The type of image to use:
  • 32-bit System.Drawing.Bitmap with alpha channel for transparency
  • System.Drawing.Icon (built-in transparency)

That plethora of choices together with the absence of COM stuff is what makes a good EnvDTE API for add-in developers.

Jeff and Suzanne, very good job!!

After four years since I started pushing Microsoft to get rid of satellite DLLs to provide custom pictures for commands of add-ins, and then pushing again and then even again, and even through private channels I have as an MVP and even through private e-mails, all that to avoid the infamous official procedure to Display a Custom Icon on the Add-in Button, finally I have received official feedback through Microsoft Connect that VS 2010 will get rid of satellite DLLs for add-ins. Quote from one of the links above:

“I wanted to let you know that the following improvements to Visual Studio 2010 were made based on your feedback:

1)    There will be support for loading a command’s bitmap from the add-in module if there is no satellite DLL or if the satellite DLL doesn’t contain the image.
2)    Commands.AddNamedCommand2 will now support an IPicture.

QA is currently testing these changes, and I cannot confirm at this time if these changes will appear in the Beta 2 release of VS 2010.”

Item #1 is self-explanatory: when you pass a bitmap Id to the AddNamedCommand method, Visual Studio will use (as a last chance) the own dll of the add-in to find the embedded bitmap associated to that bitmap Id. My suggestion was to check the add-in dll first and if not found the satellite dll (to save time not locating the satellite dll with different cultures) but it seems that the order will be the opposite to not penalize add-ins that use satellite Dlls. Anyway this news is so great that any implementation detail doesn’t matter. So, at this point the only (minor) annoyance would be that you have to map Ids with bitmaps. That is, for each command picture you have to put the same Id number in two places: in the embedded picture and in the AddNamedCommand call.

Update (March 19, 2012): I have discovered two days ago that Visual Studio 2008 already supported embedding the bitmap in the dll of the add-in, as explained here.

But there seems to be more!:

I am not sure if item #2 means what it seems (too good to be true), but it could be that a new AddNamedCommand method will be added (I guess EnvDTE100.Commands3.AddNamedCommand3 because it can’t be added to the already shipped EnvDTE.Commands.AddNamedCommand or EnvDTE80.Commands2.AddNamedCommand2) and will receive a direct IPicture rather than a bitmap Id. Oh My God… 😛

UPDATE (Sep 6). See: More (good news) on Visual Studio 2010 getting rid of satellite DLLs for add-ins

This is such a milestone in Visual Studio extensibility with add-ins as when Visual Studio 2005 introduced CreateToolWindow2 to get rid of the need ActiveX C++ shim controls to host managed .NET usercontrols in add-in toolwindows. I was even thinking about doing some experiments to create a managed satellite DLL on the fly (dynamic) using System.Reflection.Emit and using the AssemblyResolve event to supply it to Visual Studio…the pain drives creative approaches…

Getting rid of satellite DLLs and even bitmaps Ids combined with the support for 32-bit bitmaps with transparency in the alpha channel for command pictures and even backwards compatibility using the old hack RGB=0,254,0 makes the VS 2010 release really great in this regard. The person responsible for making a reality all these very welcomed enhancements is Suzanne Hansen, Program Manager of the Visual Studio Platform Shell Team. Kudos to her and her team of developers and testers!. Thank you very much indeed 🙂 I am sure I am not the only one looking forward to test the VS 2010 bits that contain these changes.

My post of a week ago “Microsoft no longer fixing (small) bugs for VS 2010, now focusing on stabilization and performance” has been commented (see the Comments section) by the DJ Park (C# IDE, Program Manager) explaining that the three bugs in the C# code model that I reported:

EnvDTE.CodeFunction.Parameters causes COM exception with add/remove methods of C# event

EnvDTE.CodeFunction.Attributes doesn’t return attributes for get/set property accessors in C#

EnvDTE.Project.CodeModel doesn’t retrieve attribute code elements in AssemblyInfo file for C#

and whose original answer was:

“We unfortunately won’t be able to address the limitation in the Project.CodeModel for the VS2010 release given that we’re purely focused on stabilization and performance but I’ve marked this bug down to be considered as we begin planning for the next release. In the meantime, I’m going to mark the bug as a “Wont Fix” but please feel free to re-activate if you have any further questions/comments.”

aren’t going to be fixed not because they are no longer fixing minor bugs on VS 2010 Beta 1 but because they are working in a new code model:

“Hey Carlos – Thanks for raising the thoughts/concerns.  I wanted to jump in to provide some more context on the bugs you mentioned.  I’d be happy to talk about this further if you’d like, so just let me know. (Quick note: I’m taking the excerpt below from a response I posted on InfoQ)

First of all, I apologize if my responses made it seem like we are no longer fixing minor issues on VS 2010. In fact, the main focus for the VS and .NET teams at this point in the product cycle is to fix bugs and do performance work in order to deliver a high quality release. To support this, we are making a conscious effort to focus on bugs and performance rather than new features or functionality. The decisions made around the EnvDTE bugs were targeted decisions and should not be taken as a broader indication that we are no longer fixing bugs.

To shed some light around the decisions regarding these C# code model bugs, the main reason we decided not to fix these issues is because we are making longer term investments in a public language model. This API will do a much better job than the existing Code Model in surfacing our compilers and will provide a richer representation of code. As a result, we decided to limit our investment in EnvDTE/CodeModel and treat regressions of existing functionality with higher priority. The bugs in question, while important, existed in previous releases.”

Since that second explanation was missing in the first response to my bugs in Microsoft Connect, that led me to the false conclusion of my post. The explanation is also now in a new fourth bug that I reported a couple of days ago:

EnvDTE.CodeElement.Name doesn’t include type placeholder for generics types or methods