Demand-Loading VSTO Add-ins

In an earlier post, I talked about how you could delay (or prevent) the loading of managed code using a native add-in. In that post I also listed the standard LoadBehavior settings, and I was assuming that everyone knows how these apply, but I got a couple of follow-up questions that prompted me to clarify the normal (LoadBehavior-based) demand-loading mechanism, and how it applies to VSTO add-ins.

It’s pretty simple: you can set up any Office COM add-in (native, managed, VSTO) for demand-loading in a standard way, that is by setting the LoadBehavior in the registry to 0x10 (16 dec). For versions of Office prior to 2007 (and for those Office apps that don’t yet support the Ribbon), the typical pattern is to create some custom CommandBar control in your add-in at startup. Office will load the add-in the first time it boots after the add-in is registered, call your add-in code to set up the custom UI, and cache this information so that when the user clicks the control, this will load the add-in.

In the case of add-ins that implement custom Ribbons, the behavior is essentially the same: Office will load the add-in the first time it boots after the add-in is registered, call GetCustomUI and cache the ribbon XML. Then, Office resets the LoadBehavior value to 8. Subsequently, when the user clicks one of the ribbon controls, this will load the add-in and set LoadBehavior to 9. This works with both a low-level IRibbonExtensibility implementation and with the VSTO designer-generated ribbon wrappers.

If you want to set LoadBehavior in your project for testing during development, you could create a regedit script, eg:

Windows Registry Editor Version 5.00








...and then add this to the project properties as a post-build step:

regedit /s "$(SolutionDir)$(SolutionName).reg"

When it comes time to deploy the solution, if you’re using a setup project, you’ll have to set the LoadBehavior by setting the value in the registry editor in your setup project.


If you’re using ClickOnce publishing, you’ll need to edit the loadBehavior attribute value manually in the application manifest (and then re-sign the manifest).


That’s it. There’s nothing else you need to do. You create your custom Ribbon either using a low-level implementation or using the VSTO designer wrappers – all in the normal way.

Comments (8)

  1. wordyone says:

    Thank you for this very informative article as well as the follow-up article. Could you please tell me where the ribbon is cached and how to reset this cache once it has been established?

    I have found that once the add-in’s ribbon has been cached, if something later changes — such as the default label or text in a combobox (populated using getText or getLabel callback) — the "bad" ribbon values persist. I would like to reset the cache somehow because resetting load behavior of my add-in to 16 again does not seem to overwrite the original ribbon that was cached.

  2. Garry Trinder says:

    wordyone – to delete Ribbon/CommandBar custom icons, you can simply delete the toolbar cache files. You should take a backup of these files first, and note that these will delete other custom settings (for example, Word’s contains style customizations etc in addition to Ribbon/CommandBar icons).

    Excel: C:Documents and Settings<user>Application DataMicrosoftExcelExcel12.xlb (or Excel11.xlb)

    Word: C:Documents and Settings<user>Application

    Outlook: C:Documents and Settings<user>Application DataMicrosoftOutlookoutcmd.dat

    PowerPoint: C:Documents and Settings<user>Application DataMicrosoftPowerpointppt.pcb

  3. wordyone says:

    Hi Andrew. Thanks for the quick response on that. A few follow-up questions on this topic, and then I think I will really get it!

    In testing this, I modified a Word 2007 VST0 2005 SE Add-in to use Load Behavior 16. On launch Word, it loads my add-in and caches the ribbon, etc. so it takes longer for Word to start up this first time. After the initial startup, the reg key changes to 9 for the delayed load scenario. The Load Behavior key doesn’t change to 8 until the user clicks a button, as described in the article. Am I doing something wrong, or is the reg key of 8 no longer in effect?

    Lastly, and more importantly, when testing with delayed load I find something odd. The first time Word starts, it takes longer because my add-in fully loads (which is expected). Then the reg key changes to 9, and Word startup time is shortened on subsequent launches. However, after I reboot the machine, Word seems to take the original amount of time to start again (same as if my add-in were fully loading). Even though the reg key for my add-in is still 9 and delayed load scenario in place. Is there something else coming in to play that can explain the longer load times following reboot?

  4. chris.snider says:

    Is there any events that we can hook for the display of the custom ribbon?  I want to be able to delay load my Powerpoint add-in using the LoadBehavior 16/9.  However, I have some custom processing required to determine if buttons should be displayed or not.  Currently, I have not been able to find any events for the Ribbon display/Onvisible/VisibleChanged etc to trap.



  5. wordyone says:

    Hi Andrew,

    I removed Normal.dotm but the earlier ribbon settings remain in Word’s "past memory of my add-in" somewhere. To reproduce this, you install your Word 2007 VSTO SE 2005 add-in with the LoadBehavior set to 3. You then modify your add-in’s ribbon so it will be pretty obvious which version of the ribbon you are seeing (the v1-original one or v2-the changed one). You then change your add-in to install with LoadBehavior 16. You uninstall the old one and reinstall the new one, and after you do this, your add-in’s original ribbon (v1) appears when Word launches. If you go to the registry and flip the reg key to 3, the modified version of the ribbon (v2) appears. Could you please shed some light on where it is caching this old version of the ribbon for my add-in?  I have tried removing Normal.dotm, as well as deleting the Data registry key.

  6. andreww says:

    chris.snyder – no, unfortunately there are no events fired when a custom ribbon is displayed. You could approach this from the other side: that is, you decide which buttons to display and then force a refresh of the control or ribbon with IRibbonUI.Invalidate/InvalidateControl.

  7. Garry Trinder says:

    wordyone – There’s a separate cache file for the XML and icon images from DemandLoad add-ins. These files are located at:


    They are named Word12.customui, Excel12.customui, etc.

    The cache is a zip file, but it is not editable by users.  If you want to get back to a blank slate, the best option is to delete all the cache files and reset all the add-ins back to LoadBehavior = 3 or 16.

  8. wordyone says:

    Andrew, Thank you again much for your timely response. This is the information we needed to get some critical issues with a customer’s build resolved.

Skip to main content