Add-ins – Where does Windows store the information?

Add-ins – Where does Windows store the information?
The purpose with this post is to give a basic understanding about where Windows registry store information about add-ins in order to load the add-ins when we start Excel through automation. It’s the first out of three posts on the subject. As for the Excel versions the 97 and 2007 are excluded.

Types of Add-ins
Since Excel can handle several different types of add-ins the best approach to try to answer the question is to use these categories.

In general add-ins can be divided into the following categories:
• XLA Add-ins (Created with Excel)
• XLL Add-ins (Created with C/C++)
• Automation Add-ins (Usually created with classic VB or with C++)
• COM Add-ins for Excel (as above)
• COM Add-ins for the VB-editor (as above)

XLAs are easy to locate in Windows registry as they only appear in two places.

If they are available and activated Windows stores the information at the following place:

If they are available but deactivated Windows stores the information at the following place:
HKEY_CURRENT_USERSoftwareMicrosoftOfficeversionExcelAdd-in Manager

“Version” refer here to the internal number versions of Excel like “9.0”, “10.0”, “11.0” etc.

The XLAs that are shipped with Excel is not located in the Add-in Manager section when deactivated instead they can be found in the HKEY_CLASSES_ROOT like the following example:

Despite the technical differences between XLAs and XLLs Windows registry store the information about XLLs in an identical way as for the XLAs.

Automation Add-ins
This type of add-ins is only available from 2002 and on forward. Compared with XLAs/XLLs the only differences are the following:

* Instead of filenames they are referred with their ProgID (Servername.Classname).
* When activated the string”/A” is added in front of the ProgID.

COM Add-ins for Excel
This category of COM Add-ins is accessed via Excel’s standard UI. Unlike the other add-ins above the subkey’s names are identical to the COM Add-ins ProgIDs and each COM Add-in has at least the following accessible information available:

– Description / Friendly Name / LoadBehavior

Unlike the other add-ins above the information for the COM Add-ins can be found in one of the following sections in the registry:
– HKEY_CURRENT_USERSoftwareMicrosoftOfficeExcelAddins
-HKEY_USERS.DEFAULT SoftwareMicrosoftOfficeExcelAddins

Information about third-part COM Add-ins (like SnagIt etc) tends to be stored in the HKEY_LOCAL_MACHINE, which may be the preferable location (at least from my point of view).

COM Add-ins for the VB-editor
This group of add-ins target the VB-Editor in Excel and the information about them are stored (in an identical way as for the COM Add-ins for Excel) in:

However, in addition to this location information is also stored in, when the COM Add-ins are activated: HKEY_CURRENT_USERSoftwareMicrosoftOfficeversionExcelOptions

Not only that, the “/A”-switch is also added to the ProgID which means that they are similar to Automation Add-ins, at least on their faces. I’ve not been able to understand the logic for this behavior so if anyone can explain it to me I would be very pleased.

Additional information about XLLs, Automation Add-ins and COM Add-in is stored in the HKEY_CLASSES_ROOT section of the registry.

For additional information please see articles listed at the following URL:
A collection of useful Excel Articles

Please let me know if I’ve missed any essential as it can be rather confusing when ‘diving’ into the registry.

In the next coming post I’ll discuss an alternative approach to Windows API when working with the Windows Registry.

Kind regards,

Posted in Uncategorized

4 thoughts on “Add-ins – Where does Windows store the information?

  1. Based on the title of the post, I wasn’t sure I’d be interested. However, I’m glad I stopped by. The link to “A collection of useful Excel Articles” is great. Just quickly scrolling down that web page I noticed several items that I am really interested in.

    I’m still not brave enough to mess with the registry, but I got something anyway.

    Thanks for posting the link, Dennis!

  2. Mike,

    You’re welcome and if You take part of the upcoming posts You’ll see that it’s primarily a question of reading info from the registry. However, from a general point of view we should avoid situation which we are not comfortable with so You stand is a reasonable and a good point.

    Kind regards,

Posting code? Use <pre> tags for VBA and <code> tags for inline.

Leave a Reply

Your email address will not be published.