Outlook automation not working with click to run (C2R) installation

Rob J 1 Reputation point

I've asked this question on 3 Nov 2020 with no response so posting here.


For years I have been automating office from 3rd party software but Microsoft 365 Click To Run versions do not register themselves on windows to allow office to be automated from 3rd party software.

However the "Click to Run" versions of "Office 365" or now "Microsoft 365" are pretty much all that seems to get installed these days.

How do we activate the "CLICK TO RUN" versions of Office so we can use office automation from 3rd party software without having to do the following:-

  1. Open Excel
  2. Open a blank workbook
  3. Click View then Macros
  4. type test and click "Create"
  5. Click Tools then References
  6. Click Browse
  7. Select Either

c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16\mso.dll
c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\mso.dll
Depending if you have 64 bit office or 32 bit office.

  1. Click OK and close the Microsoft Visual basic for Application then close Excel.

Another poster had same problem and registered typelib regtlib.exe but regtlib.exe is not on the PC. See


Can anyone please let me know how we can get Outlook to respond to the below command if the retail version of Microsoft Office or Outlook is not installed but is installed with a Click-to-run installation.


{count} votes

1 answer

Sort by: Most helpful
  1. Tom van Stiphout 1,701 Reputation points MVP

    Since you did not get a great reply yet, I will add a lousy reply. In the sense that it does not solve your problem but perhaps sheds more light on it.

    This is not necessarily an issue or CtR or MSI, but it is a correlated issue. The real issue is that a few years ago MSFT decided Office objects should live in their own protected part of the registry, not accessible by a simple CreateObject. So CreateObject fails because that object is not in your normal HKLM or HKCU hive.

    Reading the tea leaves MSFT has afterwards realized this broke a lot of apps like yours and is gradually clawing its way back.

    As an Access developer I am lucky I can install a "pre-bad_idea" version of the database engine and third party applications are OK. Unfortunately I am not at all sure a similar avenue exists for you as an Outlook developer.

    Maybe, just maybe you can use this slimy hack: realizing that all Office apps are living in the same bubble and can happily CreateObject between each other, and realizing what I just said about Access, is it possible to create an interface using Access that in turn automates Outlook? I would give that about an 80% to succeed in the hands of an expert developer.