Considerations while reading/writing registry keys under HKLM from Office Addin in Office Click-to-Run

  • Article

An add-in running on Click-to-Run (C2R) version of Office (Office 365), which creates custom registry entries under HKLM hive, will have the registry entries created in the C2R portion of the registry . For example, if your add-in tries to create a registry entry HKLM\Software\MyCustomKey then it gets created as HKLM\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\MyCustomKey (Wow6432Node assuming 32-bit Office). This is by design as C2R version uses registry redirection to achieve Application Virtualization. If your add-in is the only one writing and reading these custom registry entries, there will be no problems as the registry redirection will happen in both the cases (writing/reading).

However, you may see problems when you install Office updates. Since the C2R portion of the registry is owned by Office, the custom entries made might get deleted with Office update. This is also expected and is a by design behavior.

So, the question is how can we create custom registry entries from our Office add-ins and get away with the threat that the C2R Office update brings. Well there isn’t an ideal solution/workaround for this but below are couple of workarounds that can be used :

Workaround 1

You can create a logon script or something similar which periodically executes on the machine to do the following:

  1. Check if C2R location contains your custom registry keys.
  2. If yes, read those keys and store their state.
  3. If not, create your registry key there using the state you had saved.

Pros of this strategy: Takes less development time, no code change in your existing product is needed

Cons of this strategy: Not tightly integrated with your product, needs to run every login.

 

Workaround 2

Have an external process which will be used to write/read custom registry.

If your Office add-in which is loaded inside the Office address space creates a custom entry in registry, it will be redirected to C2R hive. To avoid this, create an external process outside Office . Whenever you need to read or write to registry, communicate with this process using something like windows messages or named pipes or .NET Remoting etc. This external process reads or writes the registry and communicate the results back to you.

Pros of this strategy:

  1. Tightly integrated with your product. You don’t need to run this every login.

Cons of this strategy:

  1. Will involve some amount of development and code changes to your add-in.