MS Office Word VSTO “Load On Demand”

Question

We have developed a product that is a standard VSTO addin (Word 2010 and Word 2013, x86 only). By default when it is installed, it is installed for all users (ie. the addin registry entries are inserted into HKLM - HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Microsoft\Office\Word\Addins).

When the value for the LoadBehavior reg key is set to 0x3 (i.e. "Load at Startup"), the addin works perfectly fine, however when we set the value for LoadBehavior to 0x10 (i.e. "Load on demand"), the addin does not work as we would expect:

Due to UAC (and that Word does not run elevated), the value of LoadBehavior in HKLM is not changed from 0x10 to 0x9 but instead is overridden by creating a LoadBehavior key (with value 0x9) in the HKCU hive.

Unfortunately, we have found that this HKCU overridden value is not taken into account unless the Manifest key is present in the HKCU hive along with LoadBehavior). More info on this related thread: https://social.msdn.microsoft.com/Forums/vstudio/en-US/3776734b-333e-423b-9c08-7c7a441c3e94/load-behavior-and-word-addin?forum=vsto

The 'obvious' remedy for this issue is to write the Manifest into HKCU for each user (as well as in HKLM) at install time OR when each user run the addin the first time. There are however some serious drawbacks with this approach:

• Uninstalling the addin requires removing every user HKCU values to prevent users experiencing loading issues (this is not recommended and poses other issues/complications such as the need to use Active Setup - Remove registry keys under HKCU on a per machine installation).
• Users which have these values in their (roaming) HKCU hive, experience issues when they login to a machine in the same domain which does not have our addin installed.

Is it a bug that the manifest is not obtained from HKLM where the LoadBehavior is set appropriately in HKCU? I think this issue would be resolved if the LoadBehavior in HKLM could be overridden in HKCU without the need for the Manifest value to be overridden as well.

Anyone knows of a way to overcome this issue?

Apocrypha

Answer 1

Short of setting the UAC to "Never Notify," I do not know of a way to overcome your issues directly. However, I am going to suggest a workaround that will allow you to essentially Load on Demand.

I suggest that you change your VSTO addin'sLoadBehavior to 0x0 (Unloaded - Do Not Load Automatically) and then use a VBA command in an automatically loaded template to control when your add-in loads. Here is an outline of the steps to take:

1. In Visual Studio make sure the ribbon in your addin is coded as an XML file (not created using the Visual Designer). Within this ribbon define a custom namespace.
2. Create a Word template (.dotm). Using the Custom UI Editor for Microsoft Office embed within this template the XML for a ribbon tab that is labeled and positioned the same as the one from your add-in. Define the namespace in the XML the same as the one in your Visual Studio XML code so that they share the same namespace. Also, define a button that will load your addin (and perhaps do additional functions within your addin as well).

3. Within your Template write a sub to load your unloaded 0x0 addin using this code:

   Application.COMAddIns(ProgID).Connect = True

   ProgID is either the item idex of your ProgID or the actual name of the ProgID in quotes.

4. Within your template write a callback that will call the code to load the addin from the button.

5. Place the template in Word's STARTUP directory. For Word 2010 that is C:\Program Files (x86)\Microsoft Office\Office14\STARTUP

What we want to happen is that when Word is launched the VSTO addin is installed but is not loaded. The template you created IS loaded automatically from the STARTUP directory and places the ribbon tab for your application within Word. Because the VSTO addin is not loaded, those controls are not currently visible. However, after implementing the steps above, when the button from the template's XML is clicked, your addin will load its controls onto the same ribbon because they share a namespace. And when Word is closed and re-launched, it resets to the VSTO addin being installed but not loaded.

Taking this a step further, if you wanted to avoid the extra click of loading the VSTO addin controls, you could conceivably recreate the VSTO addin's XML within the template and have each control call code to load your VSTO addin, hide the template's ribbon controls, and perform your addin's functionality. In this way you would have your placeholder ribbon provided by the template's XML and the real addin loading and performing actions on demand.

Rhetoric

Answer 2

The reason you are using Load On Demand most likely is to improve startup performance as described in MSDN. However, load-on-demand comes with a whole set of issues (no support for dynamic Ribbon UI state, issues with HKLM deployment etc).

As you already said, there are no issues with Load at Startup. Therefore, the recommended way to load your add-in is to use a LoadBehavior value of 0x3.

If you are facing issues with your add-ins load performance, one solution might be to use a light-weight add-in which is always loaded at startup and then this add-in acts as a loader for the actual add-in.

Imtiaz

Thanks for this @dirk-vollmar. Just to clarify, the main reason behind wanting to use LoadOnDemand is not because we have a slow add-in, but it is because we have lots and lots of add-ins that are all business critical. These compete for resources and often "conflict" and error if loaded at the same time. Alas we have to live in a world where we cannot change other's add-ins, and when you have as many as most of our clients do, you cannot ask them all to improve their load. – Apocrypha