Calling Marshall.ReleaseComObject

February 21, 2014

If you ever develop COM add-ins for the VBA editor (or for some Office application), you may find that sometimes you need to call
Marshall.ReleaseComObject (when you get strange errors that disappear when calling Marshall.ReleaseComObject) and most of the time (by default) you don’t have to (when you get an InvalidComObjectException). The issue is a bit tricky because of a number of factors, such as:
  • The RCWs are reused and cached per-AppDomain
  • An AppDomain can contain more than one .NET add-in
  • RCWs have a reference counter, and the COM-object that the RCW wraps has another reference counter.
  • There can be COM singletons involved.
  • Etc.

Here you have some useful links to get a better knowledge:

Marshal.ReleaseComObject Method
http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.releasecomobject.aspx

Marshal.ReleaseComObject Considered Dangerous
http://blogs.msdn.com/b/visualstudio/archive/2010/03/01/marshal-releasecomobject-considered-dangerous.aspx

The mapping between interface pointers and runtime callable wrappers (RCWs)
http://blogs.msdn.com/b/mbend/archive/2007/04/18/the-mapping-between-interface-pointers-and-runtime-callable-wrappers-rcws.aspx

Chapter 2: Basics of Office Interoperability (Part 2 of 3)
http://msdn.microsoft.com/en-us/library/office/aa679807%28v=office.11%29.aspx

The strange case of VBA editor prompting to repair Visual Studio (again)

February 9, 2014

On one of my computers I have started to suffer again the strange case of a prompt to repair Visual Studio 2010 when launching the VBA editor of any Office application. I already posted about this back in 2012 when I learned that a cause for that issue was having an external hard drive connected to the computer while you installed Visual Studio. When the drive was disconnected, the issue appeared. Since I did use an external hard drive as source for the setups of Visual Studio, that was certainly the case. Since then, I never have an external hard drive connected while I install Visual Studio, I copy the setups to the desktop, disconnect the drive and proceed to install.

So, what is causing the issue now, out of the blue? I am reading again the post How to work around the issue when opening Office applications repairs Visual Studio where Heath Stewart explains the issue and the workaround, and again, the cause is the presence of a drive unit that was present while Visual Studio was installed and sometime later that drive letter is no longer available. In my new cause these days, it was caused because the computer is an office laptop, and my company partitions the hard drive in two units, “C:\” for apps and “D:\” for data. Since that is plainly useless (the hard drive is the same so if broken you lose both partitions and most data goes anyway to the “Desktop” or “My Documents” locations, which are on “C:\”), a couple of days ago I removed the empty “D:\” partition and joined the space to the “C:\” partition (which was almost full). Alas, since the “D:\” unit was removed the issue with the VS 2010 prompt to repair appeared.

The post of Heath Stewart explains how to find the offending component filtering by “Warning” kind, “MsiInstaller” source and “1001” event id. But it you filter instead by “1004” event id, you will get the offending missing unit (“D:\” in my case).

I have been unable to fix the issue yet with the instructions of the post, so I have had to uninstall VS 2010. I am now gettting a prompt to repair Visual Studio 2013…oh my…, you see, the installers of Visual Studio are so crappy that if you are a developer of extensions for Visual Studio and get a new computer you know you have to spend a lot of hours installing VS 2005, SP1, VS 2008, SP1, VS 2010, SP1, VS 2012, VS 2013, tons of patches and updates, etc. and when you think it’s done, some day you discover that you need to uninstall all of them (or to format the hard drive to start again) as I did in 2012 and it seems that I will have to do this next week again…

Microsoft Office Language Packs

December 21, 2013

In the same way that Visual Studio offers language packs to have multiple languages, which is really handy for developers of VS add-ins, Microsoft Office 2010 and higher also provides language packs, although not for free:

Microsoft Office 2010 Language Packs
http://www.microsoftstore.com/store/msusa/en_US/pdp/Language-Pack-for-Office-2010/productID.253665800

Microsoft Office 2013 Language Packs
http://www.microsoftstore.com/store/msusa/en_US/pdp/Office-Language-Pack-2013/productID.259321800

which are also handy for developers of add-ins for the VBA editor, to discover, for example, that the “Standard” commandbar name is localized (“Estándar” in Spanish), when it shouldn’t.

To change the language of Office you have to go to Start, All Programs, Microsoft Office, Microsoft Office 2010 Tools, Microsoft Office 2010 Language Preferences. Programmatically, you can get the language of Office through the registry key HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Common\LanguageResources, UILanguage name.

MSADDNDR.DLL 12.0.20617.1 installed by VS 2013 Preview breaks setups of VBA add-ins

July 10, 2013

In the last couple of days two users of my add-in MZ-Tools 3.0 for VBA have reported me that the (latest) setup failed with error “Unable to register DLL/OCX:RegSvr32 failed with exit code 0x5″.

Again?

After discovering some months ago that the problem happened because Office 2013 no longer ships the MSADDNDR.DLL file, officially confirmed by Microsoft, I modified the setup to install that file if missing. Then I had to modify the setup again because apparently an older version of that file didn’t work either, so the setup installs it now “if missing” or “if present file older”.

And then, these two bug reports with the same problem? One of the users provided me the version installed on his system: 12.0.20617.1, and a copy, so I could reproduce the problem. Where does that version “12.0.20617.1” come from, if older versions were “6.x.y.z”?. At first I thought about Office 2010 (internally version 12.0), but once I verified with Orca.exe that it ships version 6.x, I searched the term 12.0.20617.1 on the web, and you know what? It is installed by VS 2013 Preview (internally version 12.0)! (I have verified and reproduced the problem). And why does it break existing setups that ship version 6.x? Because it is not backwards compatible! I explain the details in this bug report that I have opened at Microsoft Connect:

MSADDNDR.DLL 12.0.20617.1 installed by VS 2013 Preview breaks setups of VBA add-ins
http://connect.microsoft.com/VisualStudio/feedback/details/793386/msaddndr-dll-12-0-20617-1-installed-by-vs-2013-preview-breaks-setups-of-vba-add-ins

The workaround is easy: force the setup to install its version, not matter which version is installed, but I want to know from Microsoft if I will break VS 2013 doing that.

Msaddndr.dll file officially not installed by Microsoft Office 2013

April 6, 2013

As I posted back in November, the setup of an add-in for the VBA editor of Office 2013 written with VB6 could fail with the following error:

“Unable to register DLL/OCX:RegSvr32 failed with exit code 0x5″

I mentioned that the cause was that the file Msaddndr.dll is no longer installed by Office 2013 and today I have found that Microsoft wrote an official Knowledge Base (KB) article stating it a month later:

A custom add-in that uses interfaces in the Msaddndr.dll file does not work in Office 2013
http://support.microsoft.com/kb/2792179

The workaround is, of course, that your setup installs that file. BTW, I got yesterday a bug report from a user of my MZ-Tools 3.0 for VBA with that same error but using a MZTools3VBASetup.exe that already (supposedly) installed the file. It happened that the system already had that file installed, but an old version, and the setup only installed it if not present, so it was not replaced by the newest version. So, when applying this workaround, ensure that your setup installs the file if not present, or if it is an older version, because it seems that there are at least two versions of Msaddndr.dll out there.

MZ-Tools Articles Series: BUG: CommandBar.Name property localized in VBA editor of Office.

September 9, 2012

Visual Studio causes problems to developers of add-ins in localized versions (as I blogged four years ago), but it is not the only one. The automation model of the VBA editor of Microsoft Office has also problems in localized versions. The CommandBar class has the Name and NameLocal properties for the English name and the localized name, but there are commandbars with its Name property localized (non-English) and others with its NameLocal property not localized (English). This poses a challenge to add-ins for the VBA editor when trying to get a commandbar by its (English) name:

BUG: CommandBar.Name property localized in VBA editor of Office.
http://www.mztools.com/articles/2012/MZ2012020.aspx

MZ-Tools Articles Series: HOWTO: Create a setup for an add-in for the VBA editor of Microsoft Office for the current user (not requiring admin rights) using Inno Setup.

September 8, 2012

This new article shows a sample of a setup for an add-in for the VBA editor of Microsoft Office using InnoSetup. In this sample I show two interesting techniques:

HOWTO: Create a setup for an add-in for the VBA editor of Microsoft Office for the current user (not requiring admin rights) using Inno Setup
http://www.mztools.com/articles/2012/MZ2012019.aspx

MZ-Tools Articles Series: INFO: Registry entries to register an add-in for the VBA editor of Office for the current user without admin rights.

September 7, 2012

Continuing with the tutorials that I am writing about creating add-ins for the VBA editor of  Microsoft Office with Visual Studio and the .NET Framework, a new interim article between the last ones with sample code and the next ones that will come with sample setups:

INFO: Registry entries to register an add-in for the VBA editor of Office for the current user without admin rights.
http://www.mztools.com/articles/2012/MZ2012018.aspx

This article provides the solution to two common issues with add-ins of the VBA editor: “How can I install an add-in without admin rights?”, and “After installing the add-in, I don’t see it”.

MZ-Tools Articles Series: HOWTO: Create a toolwindow for the VBA editor of Office from an add-in with Visual Studio .NET.

September 6, 2012

The next article about creating an add-in for the VBA editor of Office with the .NET Framework, and before writing articles related to the setup, is about creating toolwindows. If you thought it was going to be easy…it’s tricky as hell, with several issues. But fortunately I have found workarounds for all of them:

HOWTO: Create a toolwindow for the VBA editor of Office from an add-in with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012017.aspx

MZ-Tools Articles Series: HOWTO: Create a button with a custom picture for the VBA editor of Office from an add-in with Visual Studio .NET.

September 4, 2012

After explaining how to create buttons with a built-in Office picture using the CommandBarButton.FaceId property, the next step is to use custom pictures. Tricky as always for the conversion from .NET bitmap to OLE IPictureDisp, but at least fortunately the use of the clipboard (CommandBarButton.PasteFace) is no longer necessary as it was in initial versions of Microsoft Office and in VB5/VB6 add-ins.

HOWTO: Create a button with a custom picture for the VBA editor of Office from an add-in with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012016.aspx