Remote Typelibs and the Outlook Object Model

As I’ve mentioned before, I don’t like to install Office on my build servers. Neither do some of my customers, one of whom reported that they couldn’t get their Outlook 2010 based object model code to compile on their build servers.

The problem they reported was in their #import statements. They looked something like this:

#import "\\RemoteMachine\c$\Program Files (x86)\Common Files\Microsoft Shared\Office14\MSO.DLL" rename_namespace("OL")
#import "\\RemoteMachine\c$\Program Files (x86)\Microsoft Office\OFFICE14\msoutl.olb" rename_namespace("OL") rename ("GetOrganizer", "GetOrganizer1")

Note that they’re pointing the compiler at binaries installed on another machine to #import from. When they pointed these at Outlook 2007’s type libraries, the #import was successful. But when they pointed it at Outlook 2010’s type libraries, they got this:

error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder

Now – we quickly discovered that despite this error, the compiler still produced .tli and .tlh files for both mso and msoutl, so subsequent compilations worked, and we could ignore the error with #pragma warning(disable:4772), but this didn’t feel like a satisfactory solution. The compilations only succeeded because they weren’t using anything out of the type library which had __missing_type__ on it, so as their development continued, they were likely to hit a roadblock.

The question then was why the C4772 error happened in the first place. We look at the documentation for the error, which states:

“However, the type library contained a reference to another type library that was not referenced with #import...If you want the compiler to find type libraries in different directories, add those directories to the PATH environment variable”

So some dependency wasn’t found for one of our type libraries. Experimentation showed that mso.dll imported without error and msoutl.olb was the one having a problem. We used Procmon during compilation and saw that, right after the compiler started looking at msoutl.olb, it went crazy trying to find a copy of mso.dll. It looked in every directory on the path. This is consistent with what we saw in the documentation for C4772, so we tried placing a copy of mso.dll in one of the directories on the path. Success! Everything compiled just fine.

I still wasn’t satisfied that we had a resolution though, since a check on a machine with Outlook installed showed that mso.dll wasn’t on the path their either, yet compilation succeeded. And then there was the report that Outlook 2007 type libraries did not exhibit this problem. So we ran Procmon on the machine with Outlook installed and watched what happened during compilation. ProcMon showed that while we were processing msoutl.olb, we did find mso.dll. We found it by looking in the registry under typelibs, specifically, under this key:

HKEY_CLASSES_ROOT\TypeLib\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}\2.5

Now things were starting to clear up. During the installation of Office, one of the things the installer did was register a version of mso.dll under the TypeLib key. This registration is what allowed the compiler to find a copy of mso.dll while it was processing msoutl.olb. Returning to the build server, we found that while we did not have this 2.5 subkey, we did have a 2.4 subkey which pointed to a copy of Outlook 2007’s version of mso.dll which happened to be on the server, presumably installed by some other product which had a dependency on mso.dll.

This, then, is our resolution – if we want the compiler to handle type libraries which have a dependency on a specific version of mso.dll, we need to register that version under the TypeLib key. The simple way to do this is to export the key from a machine where Outlook is installed, then import it on the build server after correcting the path. Here’s what mine looked like:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\TypeLib\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}]
[HKEY_CLASSES_ROOT\TypeLib\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}\2.5]
"PrimaryInteropAssemblyName"="Office, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
@="Microsoft Office 14.0 Object Library"
[HKEY_CLASSES_ROOT\TypeLib\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}\2.5\0]
[HKEY_CLASSES_ROOT\TypeLib\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}\2.5\0\win32]
@="\\\\RemoteMachine\\c$\\Program Files (x86)\\Common Files\\Microsoft Shared\\Office14\\MSO.DLL"
[HKEY_CLASSES_ROOT\TypeLib\{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52}\2.5\FLAGS]
@="0"

Once this bit of type library magic was put in place, we were able to compile without error.

BTW – some interesting reading on type libraries that I found useful in figuring this out:

http://blogs.msdn.com/b/larryosterman/archive/2006/01/09/510856.aspx

http://msdn.microsoft.com/en-us/library/ms221610(VS.71).aspx

http://msdn.microsoft.com/en-us/library/ms221570(VS.71).aspx

Enjoy!