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.