Article ID: 290868 - View products that this article applies to.
This article was previously published under Q290868
Office supports two kinds of Component Object Model (COM) Add-Ins: those that are global to the system and are loaded for all users, and those that can be installed on a per-user basis. When you build an add-in by using the Add-in Designer (Msaddndr.dll) for Visual Basic (VB), the add-in is registered as a per-user add-in. You cannot override this behavior, but you can work around it.
This article discusses how to register an Office COM Add-in for all users when using the VB Add-in Designer.
Office COM Add-ins register themselves for a particular Office application when performing COM registration (that is, when the DllRegisterServer function is called from Regsvr32.exe or a setup package). The add-in uses either the HKEY_CURRENT_USER or the HKEY_LOCAL_MACHINE registry hive to determine whether it should be treated as a per-user add-in or a system add-in, respectively.
Add-ins that are registered under HKEY_CURRENT_USER apply to that user only, and can be enabled and disabled on a user-by-user basis. Add-ins that are registered under HKEY_LOCAL_MACHINE are global to the system and load for all instances of that application. However, they do not appear in the application's COM Add-Ins dialog box, and they cannot be turned on or off for particular users.
The VB Add-in Designer is written to build per-user add-ins. If you need to make a system add-in or you want to make a more robust per-user add-in, you can use the additional registry data section of the designer object to specify a custom registration path for your add-in.
For additional information about building Office COM Add-Ins by using the Designer, and on the meaning of the registry values, click the following article number to view the article in the Microsoft Knowledge Base:
238228The examples below assume that you are using the designer add-in example that is given in the article that is listed above. However, you can apply these techniques to any COM Add-in project.
(http://support.microsoft.com/kb/238228/ )How to build an Office 2000 COM Add-In in Visual Basic
Registering a COM Add-In as a System Add-InTo register the add-in as a system add-in, you need to duplicate the registration under the HKEY_LOCAL_MACHINE path for the application for which the add-in is written. In the add-in example this is Microsoft Excel, but this works for other Office applications as well.
To use this workaround you need to know the ProgID for the connection object that your dynamic-link library (DLL) exports so that you can specify it in the registry key name. In the example, MyAddin.Connect is the default name for the DLL project and designer object, but if you change these values in your project, you need to change them in the registry key name as well.
For additional information about COM Add-Ins, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/288771/ )How to create a transparent picture for Office CommandBar Buttons
230876For more information, see the following Microsoft Developer Network (MSDN) Web sites:
(http://support.microsoft.com/kb/230876/ )BUG: CommandBar control reference becomes invalid before COM Add-In's OnDisconnection event fires
Developing COM Add-Ins for Microsoft Office 2000
http://msdn.microsoft.com/en-us/library/aa155640.aspxCOM Add-ins part I: Introducing an Office 2000 solution for the entire (Office) family
Article ID: 290868 - Last Review: August 30, 2004 - Revision: 5.5
Contact us for more help