This is the first article of the series devoted to creating add-ins for the VBA editor (32-bit / 64-bit) of Microsoft Office that I announced here.
It discusses the use of private vs Primary Interop Assemblies for Office, the .NET Framework 2.0 vs 4.0 to use and how to generate the private interop assemblies.
HOWTO: Generate Interop assemblies to create an add-in for the VBA editor (32-bit or 64-bit) of Office with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012011.aspx
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
When I thought that I have fixed the bug that I explained in my last post, I found another subtle one: in VS 2010 and 2012, setting to False the Visible property of a CommandBarPopup was not honored if the CommandBarPopup was created on a context menu (for example, in the Code Window context menu), but it worked if created on a Toolbar (for example, the Standard toolbar).
This is another bug introduced in the WPF-based commandbars of VS 2010, since it works as expected in VS 2008 and before. Unfortunately I was unable to detect these two bugs back in 2009 during the VS 2010 beta since MZ-Tools 6.0 did not offer the more complete customization offered by the new MZ-Tools 7.0 version to show / hide buttons and dropdown menus. But fortunately, the workaround is as easy as adding the children CommandBarButtons before setting the Visible property to False.
I have written a small article to document it:
BUG: Setting CommandBarPopup.Visible to False doesn’t work when CommandBarPopup in context menu.
http://www.mztools.com/articles/2012/MZ2012008.aspx
And I have reported the bug to Microsoft Connect (currently awaiting to be acknowledged):
A couple of days ago a customer of the new version MZ-Tools 7.0 for Visual Studio reported a bug regarding the dropdown menus visibility not preserved across Visual Studio sessions. I isolated the bug which happened to be a bug in the WPF-based commandbars of Visual Studio 2010 (and 2012), not happening in VS 2008 and before.
I have written a small article to document it:
BUG: CommandbarPopup.Caption changes CommandbarPopup.CommandBar.Name and viceversa.
http://www.mztools.com/articles/2012/MZ2012007.aspx
And I have reported the bug to Microsoft Connect (currently awaiting to be acknowledged):
I have got a new laptop (an Apple MacBook Air 11″) and after installing BootCamp, Windows 7, VB6, VS 2005, 2008 and 2010, yesterday I noticed that when loading MZ-Tools 3.0 for VB6, it prompted to repair Visual Studio 2010. I had received the same or similar issue from 2 or 3 users these last years that I never knew how to solve, so I could only recommend to repair or reinstall Office, VB6 ,etc. Today I have investigated more and it seems that there are multiple causes but one of them documented by Heath Stewart was certainly my case:
How to work around the issue when opening Office applications repairs Visual Studio
http://blogs.msdn.com/b/heaths/archive/2009/05/29/how-to-workaround-the-issue-when-opening-office-applications-repairs-visual-studio.aspx
That is, if there was an external drive connected when you installed Visual Studio, you get the issue when you load some Office application, or some application using VB/VBA. Of course this issue doesn’t happen if you install from the DVD, because the drive (typically D:) will be there always, but it happens if you have an external drive connected, specially if that is the drive where you are installing from!. It happened that other times I copied the setups to the internal hard drive before installing Visual Studio, but since the MacBook Air has only 128 GB of internal hard drive, I installed from an external drive.
That said, the workaround proposed in the post didn’t work for me. I guess that using the variable %ProgramFiles% on my Windows 7 64-bit rather than %ProgramFiles(x86)% didn’t help. Anyway, I got it so messed that finally I had to uninstall completely VS 2005, 2008 and 2010, which is a horrible experience because you have to uninstall lots and lots of separate setups (Visual Studio is by far the worst product regarding uninstallation). Then I started again the installations, but this time copying the media to the internal hard disk (it is a good thing to have USB 3.0 technology). And now I have 27 updates to install from Windows Update, but the issue is solved.
I hope this help others, and myself in the future 😉