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

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…