Office COM addins can be registered in one of two ways:
Per User addins will be loaded for the user that the addin was registered to. This is the common situation with addins created in VB6. Typically, this means that whatever user was logged in when your addin was installed, is the ONLY user that it will be registered for.
It’s simple enough to run regsvr32 again on your addin dll while logged in as a different user to register it for the new user but this can really be a pain in a big IT shop.
Per user addins are registered under the HK_Current_Key hive in the registry. For instance, Word add ins can be found here:
HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins
Other Office apps, namely Excel, PowerPoint and Outlook, store their addin entries in similar locations in the registry.
Per Machine addins, on the other hand, are registered in the same key, but in the HKEY_LOCAL_MACHINE hive, so, for instance, here:
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Word\Addins
Per Machine addins have the benefit of being registered once but loaded no matter what user is logged in. Definitely a bonus if you commonly have multiple users on a machine.
The problem is, VB6 automatically sets up the addin designer object such that it registers add ins as Per User addins.
This is pretty easy to fix, however.
Here’s a snippet from the very top of a DSR file for a Word addin (Open the file using notepad or some other text editor, NOT using VB6):
VERSION 5.00
Begin {AC0714F6-3D04-11D1-AE7D-00A0C90F26F4} WordAddIn
ClientHeight = 6465
ClientLeft = 4815
ClientTop = 1215
ClientWidth = 10020
_ExtentX = 17674
_ExtentY = 11404
_Version = 393216
Description = “My Word COM Add In”
DisplayName = “MyAddIn”
AppName = “Microsoft Word”
AppVer = “Microsoft Word 9.0”
LoadName = “Startup”
LoadBehavior = 3
RegLocation = “HKEY_CURRENT_USER\Software\Microsoft\Office\Word”
End
Note the RegLocation element.
Simply change that to HKEY_LOCAL_MACHINE (but leave the rest of the key alone), recompile and Presto! Your add in is now a Per Machine addin.
There’s only one snag with this, though. Every time you make a change to your DSR file, VB will automatically switch that entry back to HKEY_CURRENT_USER. Oh, the helpfulness.
But, never fear, there’s a solution here as well. Just never change the DSR<g>.
Seriously though. Simply create a separate class, expose some public methods on it that mirror the event signatures of those in the DSR file itself, and then pass the events on through the DSR to your new class.
That way, your DSR file never has to change, but you can change your class all you want and never have to worry about VB switching up the RegLocation on you.
For instance, in your DSR file, there will generally be an AddinInstance_OnConnection event that is fired when the host application is loading up your addin. Define it something like the following:
Dim rAddinClass as AddInClass
Private Sub AddinInstance_OnConnection(ByVal Application As Object, _
ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, _
ByVal AddInInst As Object, custom() As Variant)
'Create and Initialize a base class
Set rAddinClass = New AddInClass
rAddinClass.OnConnection Application, ConnectMode, AddInInst
End Sub
Then, in your AddInClass.cls file, define a function like
Public Sub OnConnection(ByVal Application As Object, _
ByVal ConnectMode As AddInDesignerObjects.ext_ConnectMode, _
ByVal AddInInst As Object, custom() As Variant)
'Do Whatever you need to do during the OnConnection event here
End Sub
When the host app (could be Outlook, Word, Excel, or PowerPoint, they all work the same), loads your addin, it will fire the OnConnection event. The sub in your DSR file will get called, which will then call the corresponding sub in your Addin Class and you can do whatever coding you need to do, never having to change the DSR file again.
Or you can try to write addins in VB.NET using VSTO, suck up about 10x the diskspace and memory, and have to deal with things like COM shims, and other splinters of joy.
