I should have written the following article near two years ago, but also Microsoft should have provided this way of creating commands with custom pictures without the need for satellite dlls 10 years ago, since the very beginning of VS.NET 2002:
HOWTO: Create a command with a custom picture without using a managed satellite DLL for a XML-based Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012004.aspx
The history has been quite compolicated:
- Visual Studio .NET 2002 and 2003 only supported COM-based add-ins that required native Visual C++ Win32 satellite dlls to provide custom pictures.
- Visual Studio 2005 introduced XML-based add-ins (using an .AddIn file to register the add-in within Visual Studio) and managed (VB.NET/C#) satellite dlls.
- As documented in the Microsoft Connect Bug Report 336868, I requested to Microsoft during the VS 2010 beta to following: “Satellite DLLs (managed or native) should not be required. They may be OK for string localizations, but please don’t force us to create satellite DLLs for pictures that could be in the own assembly add-in.”
- In the same bug report, Suzanne Hansen (the Program Manager of Visual Studio Platform Shell Team at that time) answered that (in VS 2010) “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.”
- And that was my knowledge of the matter until two days ago, when while writing the add-ins for the article I discovered that Visual Studio 2008 already supported providing custom pictures in a resource file of the add-in dll rather than through a satellite dll. Alas, the same doesn’t apply to Visual Studio 2005, which insists on finding a “.resources.dll” satellite assembly, which is a pity, because if your add-in targets VS 2005, 2008 and 2010 with the same .NET Framework 2.0 dll, you need to provide the satellite dll.
- And there is more! As I posted back in 2009, the EnvDTE80.Commands2.AddNamedCommand2 was changed internally in VS 2010 to accept a managed (.NET) System.Drawing.Bitmap or System.Drawing.Icon. I will try it and this will be the subject of another article if I am successful.