For the past years I have been writing articles in the MZ-Tools Series and posts in this blog about developing add-ins with Visual Studio .NET for Visual Studio .NET, using the .NET Framework. All this knowledge comes from my experience developing since 2002 the versions 4.0, 5.0, 6.0 and 7.0 of my MZ-Tools add-in for Visual Studio. As you may know, I have also the MZ-Tools 3.0 version for Visual Basic 6.0, 5.0 and the VBA editor, that I created with Visual Basic 6.0 back in 2000.

When Office 2010 came out, for the first time there was a 64-bit version, not only a 32-bit version, and, alas, the VBA editor of the 64-bit version doesn’t support 32-bit COM add-ins. So, MZ-Tools 3.0 for VBA doesn’t support Office 2010 64-bit. I have received some requests to support it, and things only will get worse as more developers install the 64-bit version. The same is happening to other developers creating add-ins for the VBA editor. Until now, the common answer was that it was not possible, since VB6 can only create 32-bit COM add-ins and Office 2010 64-bit can’t use 32-bit COM add-ins.

About 3 months ago I devoted some thoughts about it and I got the idea of developing an add-in for the VBA editor of Office 64-bit using the .NET Framework, since .NET assemblies can be 64-bit, and .NET assemblies can be registered as COM components… I was so excited that I halted the development of MZ-Tools 7.0 during a week to make a prototype and after several difficulties…I succeeded  :-).

Not only I got a Hello World prototype, but I also managed to create toolbars, buttons, toolwindows, to use a single NET .dll and setup to target the 32-bit and 64-bit versions of the VBA editor and as bonus tracks, to install the add-in without admin rights and to avoid the use of the clipboard to use custom pictures in buttons (two common sources of issues of MZ-Tools 3.0 for VBA).

So I am going to write a few articles in the next weeks to document the whole approach from start (Hello World) to end (the setup). Of course, I will keep writing about Visual Studio add-ins.

PS: the (great) future of MZ-Tools 3.0 for VB6/VB5/VBA will be announced in the MZ-Tools blog in the next months.

My new tutorial explains how to get the assemblies that Visual Studio shows in the .NET tab of the Add Reference dialog, since they are not the assemblies in the Global Assembly Cache (GAC):

HOWTO: Get assemblies of the Add Reference dialog from a Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012010.aspx

So, normally assemblies are located at two places: in some folder (to be used at development time by Visual Studio) and in the GAC (to be used by the application when deployed).

There are rare occasions where an assembly is only in the GAC, but you can even add a reference to an assembly in the GAC as I explained in this other article:

HOWTO: Reference a Visual Studio assembly in the GAC from an add-in
http://www.mztools.com/articles/2007/mz2007012.aspx

I have received several bug reports in the last years about MZ-Tools for Visual Studio .NET that after some investigation I have discovered that the bugs only happen when certain 3rd party add-in or package is installed, or even not installed. For example, this one only happens when CodeRush is installed. And this other one only happens in VS 2008 if the Code Analysis Tools are not installed. And I have found another ones that I have not even documented in this blog, just patching my code to prevent them.

Since diagnosing those bugs is extremely difficult without that information, my new MZ-Tools 7.0 for Visual Studio includes in the bug reports information about loaded add-ins and installed products. I have created an article with a sample add-in to show how to get that information:

HOWTO: Get loaded add-ins and installed products from a Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012009.aspx

The article explains too a Registry redirection that Visual Studio 2010 and higher does, which I mentioned the first time in this post.

And you can get even more information to be included in bug reports here:

HOWTO: Detect installed Visual Studio editions, packages or service packs
http://www.mztools.com/articles/2008/MZ2008003.aspx

This one that I mentioned in my last post that I would investigate has been extremely easy:

HOWTO: Create a command with a custom picture using an ImageList for a XML-based Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012005.aspx

And Microsoft updated correctly the documentation for Visual Studio 2010 regarding the new possibilities of the Bitmap parameter of the EnvDTE80.Commands2.AddNamedCommand2 method:

EnvDTE80.Commands2.AddNamedCommand2
http://msdn.microsoft.com/en-us/library/envdte80.commands2.addnamedcommand2(VS.100).aspx

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.

When a CommandBarButton is created from a Command on a Visual Studio menu, it has an icon and a text. However, when it is created on a toolbar, it can have only an icon, or an icon and a text. Typically buttons on a toolbar have only an icon (without a text). There are two ways to set that style (only the icon) to a CommandBarButton on a toolbar:

• Setting the CommandBarButton.Style = MsoButtonStyle.msoButtonIcon. This approach has the drawback that Visual Studio first creates the button with icon and text, and then it changes it to icon only.
• Setting the default style of a command to EnvDTE80.vsCommandStyle.vsCommandStylePict, so that CommandBarButtons created on toolbars have only the icon, while those created on menus have icon with text (the only possible style for them).

My latest article shows a sample of the second approach:

HOWTO: Set the default style a CommandBarButton on a toolbar from a Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012003.aspx