Article ID: 290868 - Last Review: August 30, 2004 - Revision: 5.5 How to configure an Office COM Add-In for all users on a systemThis article was previously published under Q290868 SUMMARY 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. MORE INFORMATION 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: 238228
(http://support.microsoft.com/kb/238228/
)
How to build an Office 2000 COM Add-In in Visual Basic
The 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. 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.
REFERENCES
For additional information about COM Add-Ins, click the following article numbers to view the articles in the Microsoft Knowledge Base:
288771
(http://support.microsoft.com/kb/288771/
)
How to create a transparent picture for Office CommandBar Buttons
230876
(http://support.microsoft.com/kb/230876/
)
BUG: CommandBar control reference becomes invalid before COM Add-In's OnDisconnection event fires
For more information, see the following Microsoft
Developer Network (MSDN) Web sites:
Developing COM Add-Ins for Microsoft Office 2000 http://msdn.microsoft.com/en-us/library/aa155640.aspx
(http://msdn.microsoft.com/en-us/library/aa155640.aspx)
COM Add-ins part I: Introducing an Office 2000 solution for the entire (Office) familyhttp://msdn.microsoft.com/en-us/library/aa155767(office.10).aspx
(http://msdn.microsoft.com/en-us/library/aa155767(office.10).aspx)
| Article Translations
|
Back to the top
