At work, I maintain an Access 2010 database that interfaces with Word, Excel and Outlook. Recently, Lync 2013 was rolled out across the office, without upgrading the rest of Office. Suddenly all interop calls started failing with “Automation error. Library not registered.” errors.
A bit of digging revealed that the Lync 2013 installation process adds registry entries for the Office 2013 (i.e. version 15) automation libraries, regardless of whether the individual 2013 applications are installed. The solution is to remove the offending registry keys, keeping the version 14 keys in place.
I put together the following .reg file to remove the keys for Outlook, Word and Excel respectively:
Windows Registry Editor Version 5.00
[-HKEY_CLASSES_ROOT\TypeLib\{00062FFF-0000-0000-C000-000000000046}\9.5]
[-HKEY_CLASSES_ROOT\TypeLib\{00020905-0000-0000-C000-000000000046}\8.6]
[-HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046}\1.8]
There doesn’t seem to be an official Microsoft solution for this – I previously repairing the Office 2010 installation but this had no effect.
Great solution, than you for posting it!!!
I’m experiencing the same problem with a Visual Studio for Office application that automates Excel 2010. Editing the registry to remove the 2013 primary interop solves the issue. However when Lync updates are pushed out the 2013 Excel interop is restored again.
Yep, same here. My employer’s IT team (which I’m not part of) keep rolling out Lync updates and every time it breaks the application I develop and support so I have to run the fix on everyone’s machine :(
I’m thinking of adding some code to my app to automatically delete the offending keys, at least until my employer decides to upgrade everyone to Word/Excel/Outlook 2013.
Much thanks- this broke my Bluebeam install – was reporting library not registered errors!