Reputation: 160
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:
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?
Upvotes: 17
Views: 2024
Reputation: 3175
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:
.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). 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.
Within your template write a callback that will call the code to load the addin from the button.
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.
Upvotes: 1
Reputation: 176269
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.
Upvotes: 0