Registry Entries

All VSTO add-ins require registry entries that specify the manifest name, manifest location and the load behavior of the add-in.


DescriptionString (REG_SZ)A brief description of the add-in. This is the name displayed to the user.
FriendlyNameString (REG_SZ)The descriptive name that is displayed in the COM add-ins dialog box. The default value is the add-in ID.
LoadBehaviorDWORD (REG_DWORD)The load behaviour of the add-in.
See the table below for a list of possible values.
ManifestString (REG_SZ)The full folder and filename of the application manifest. This must be a local path.

If you have Visual Studio 2010 Tools for Office Runtime SP1 installed on your development machine, you must add the prefix "file:///". If this prefix is not used and your add-in reads data from the application configuration file, users might receive an error when the add-in loads.

Introduced for Office 2007 to combine ManifestLocation and ManifestName.
ManifestLocationString (REG_SZ)(Office 2003 only)
C:\Program Files\Company\
The folder path of the application manifest. Only applicable for Office 2003.
ManifestNameString (REG_SZ)(Office 2003 only)
myaddin.dll.manifest
The file name of the application manifest. Only applicable for Office 2003.
WarmupDWORD (REG_DWORD)(Optional) Indicates that the .NET Framework and the VSTO Runtime load before an add-in loads. This reduces the perceved time to load. Set this value to 1. Only applicable for Outlook 2010 add-ins deployed using Windows Installer.

| vstolocal
If you are using Windows Installer to deploy your solution then appending "|vstolocal" tells the VSTO Runtime to run the solution from the location indicated by the manifest value and not loaded into the ClickOnce cache
Not including this postfix will cause the runtime to copy the customization into the ClickOnce cache.


If you are using a Setup project (ie Windows Installer) to deploy your solution you must append "|vstolocal" to the end of this path.
When a solution is built from Visual Studio then the "| vstolocal" is automatically added to the Manifest value.


LoadBehavior DWORD

This value describes the load behaviour of the COM Add-in.
This value can be a bitwise or of any of the following values

0Disconnected. The add-in is not loaded.
1Connected. The add-in is loaded.
2Load at Startup. The add-in will be loaded and connected when the host application starts.
8Load on Demand. The add-in will be loaded and connected when the host application requires it (for example when a user clicks a button that uses functionlaity in that add-in).
16Connect First Time. The add-in will be loaded and connected the first time the user runs the host application after registering the add-in.

Possible Values

0DisconnectedThe add-in is not loaded when the host application starts. It can be loaded from the COM Add-ins dialog box or programmatically, which sets the status to 1.
1ConnectedThe add-in is not loaded when the application starts. It can be loaded from the COM Add-ins dialog box or programmatically.
2DisconnectedThe add-in is loaded when the host application starts. Once the add-in is loaded it will always remain loaded until explicitely unloaded. Changing the status to 3
3ConnectedThe add-in is loaded when the host application starts. Once the add-in is loaded it will always remain loaded until explicitely unloaded.
8DisconnectedThe add-in is loaded and connected when the host application requires it. Changing the status to 9.
9ConnectedThe add-in is loaded and connected when the host application requires it.
16DisconnectedThe add-in loads when the user runs the host application for the first time, and it creates a button or menu item for itself. The next time the user starts the application, add-in is loaded on demand. Changing the status to 9.

Registry Entries

Any solutions that target Office 2007 or later require the manifest key to point to the .vsto file.
Microsoft Office 2010 applications can load add-ins that are registered under both HKCU and HKLM]
If you are using ClickOnce to deploy your add-in the add-in can only be registered under HKCU.


Office 365, Office 2019, Office 2016, Office 2013 and Office 2010
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID \ Description
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID \ FriendlyName
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID \ LoadBehavior
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID \ Manifest - (.vsto file)
The registry key for the globally unique class identifier (under Software\Classes\) is no longer required.


Office 2007
Microsoft Office 2007 applications only recognise add-ins that are registered under HKCU (by default).


Office 2003
Any solutions that are targetting Office 2003 require the manifest key to point to the .manifest file.
Any solutions that are targetting Office 2003 must have a globally unique class identifier under Software\Classes\CLSID.
The registry keys that are required for a 2003 VSTO add-in are:
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID \ Description
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID \ FriendlyName
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID \ LoadBehavior
HKEY_CURRENT_USER\Software\Microsoft\Office\ "application name" \ Addins \ ID \ Manifest - (.manifest file)


HKEY_CURRENT_USER\Software\Classes\CLSID\ "addin CLSID"
HKEY_CURRENT_USER\Software\Classes\CLSID\ "addin CLSID" \ InprocServer32
HKEY_CURRENT_USER\Software\Classes\CLSID\ "addin CLSID" \ InprocServer32 \ (Default)
where Default = %CommonProgramFiles% \ Microsoft Shared \ VSTO \ 8.0 \ AddinLoader.dll (Visual Studio 2008 or Visual Studio 2005 with Outlook)
where Default = mscoree.dll
where Default = C:\Winnt\System32\mscoree.dll


HKEY_CURRENT_USER\Software\Classes\CLSID\ "addin CLSID" \ InprocServer32 \ ManifestLocation
HKEY_CURRENT_USER\Software\Classes\CLSID\ "addin CLSID" \ InprocServer32 \ ManifestName
HKEY_CURRENT_USER\Software\Classes\CLSID\ "addin CLSID" \ InprocServer32 \ ThreadingModel


HKEY_CURRENT_USER\Software\Classes\CLSID\ "addin CLSID" \ ProgID
HKEY_CURRENT_USER\Software\Classes\CLSID\ "addin CLSID" \ Programmable
HKEY_CURRENT_USER\Software\Classes\CLSID\ "addin CLSID" \ VersionIndependentProgID


The "add-in CLSID" represents the globally unique class identifier of your add-in.
Once the add-in has been installed and registered most of the keys under "HKEY_CURRENT_USER\Software\Microsoft\Office\" become redundant.
The only item which does something is LoadBehavior.


Local Machine vs Current User

It's a hierarchy of configuration where the most specific one is applied.
LM is general, machine-wide, all users.
CU is concrete user specific, so it takes precedence.
The only key (over)written was LoadBehaviour, everything else was still coming from LM hive.
LM is for all the users.
But if one user doesn't want to use an add-in, it's disabled for that particular user by writing LoadBehviour under CU, not disabling it for all the others.
Try re-enabling the add-in from Word before deleting the registry key and the entry to see what would happen.



© 2022 Better Solutions Limited. All Rights Reserved. © 2022 Better Solutions Limited TopPrevNext