I have a COM Outlook addin which implements a ribbon button in Outlook 2010. It’s been working just fine for quite some time. Until someone tried to load the addin in the Korean version of Outlook. The ribbon buttons show up but do not do anything when clicked. In the debugger, I see the error message below whenever I click on the ribbon button “ERROR : Unable to load Typelibrary. (HRESULT = 0x8002801d)
Verify TypelibID and major version specified with
IDispatchImpl, CStockPropImpl, IProvideClassInfoImpl or IProvideCLassInfo2Impl”.
I never hit my break point in the callback for this button, so something is going on in the event layer above my code I think. But I don’t know what and I don’t know why using the Korean version of Outlook should make any different. Anyone have any ideas?
I’m thinking it has something to do with the LIBID_Office macro used below when defining the interfaces my main addin supports:
, public IDispatchImpl<IRibbonExtensibility,
&__uuidof(IRibbonExtensibility),
&LIBID_Office, /* wMajor = */ 2, /* wMinor = */ 4>
The macro is defined as
extern "C" const GUID __declspec(selectany) LIBID_Office =
{0x2df8d04c,0x5bfa,0x101b,{0xbd,0xe5,0x00,0xaa,0x00,0x44,0xde,0x52}};
The typelib lookup it is failing on is the COM addin’s own typelib. ProcMon shows Korean Outlook trying to get the typelib from HKCR and failing. There’s no reason why it should fail, I can see the registration clearly in regedit under the HKCR key.
As I said before, my addin is installed for current user, so all registrations get done under “HKCU\Software\Classes”.
When I hack in a registry entry for my typelib under “HKLM\Software\Classes”, suddenly Korean Outlook finds everything fine and the addin works.
When the addin starts up, I’m just going to have it create the typelib entry under HKLM. It’s a hack, but I don’t know what the heck MS is having Outlook do in Korean (possibly other languages?) when looking up entries in HKCR.