Register add-in to HKLM automatically

[JvF]

I have built an add-in using VB6 for outlook. When I build the DLL it
places the registry entries automatically into HKCU as I expect. What
I want is to have the registry entries (all of them) go to HKLM
instead when I make the DLL (this is important as I plan to send this
out as an install and I want them to run it and forget it - not have
to change the registry manually). I can add almost all to HKLM myself
using the Advanced Tab of the AddInDesigner but the DLL fails to load
when I put LoadBehavior there.

On a possibly similar note, this may be because whenever I make my DLL
it loads the original settings I once had for DisplayName and
Description even though I have removed these from the General tab
before I create my DLL - What is going on there?

Also, when I put CommandLineSafe and LoadBehavior in Addin Specific
Data as DWORDs when they do appear in the registry the values are
different than what I entered...???

Thanks for your assistance!

 

[Peter Young]

I have built an add-in using VB6 for outlook. When I build the DLL it
places the registry entries automatically into HKCU as I expect. What
I want is to have the registry entries (all of them) go to HKLM
instead when I make the DLL (this is important as I plan to send this
out as an install and I want them to run it and forget it - not have
to change the registry manually). I can add almost all to HKLM myself
using the Advanced Tab of the AddInDesigner but the DLL fails to load
when I put LoadBehavior there.

On a possibly similar note, this may be because whenever I make my DLL
it loads the original settings I once had for DisplayName and
Description even though I have removed these from the General tab
before I create my DLL - What is going on there?

I don't know about Office, but VB6 add-in registry entries must be located in HKCU. You can't put them in HKLM - which
is good because otherwise, how would each user be able to specify their own add-in settings?

Also, when I put CommandLineSafe and LoadBehavior in Addin Specific
Data as DWORDs when they do appear in the registry the values are
different than what I entered...???

Note that setting a VB add-in to load at startup and from the command line is not possible - the two are mutually
exclusive, and the startup setting will take precedence. I don't know that this is documented anywhere, I just know it
to be true from observation.

-Pete

 

[Stephen Bullen]

Hi JvF,

I have built an add-in using VB6 for outlook. When I build the DLL it
places the registry entries automatically into HKCU as I expect. What
I want is to have the registry entries (all of them) go to HKLM
instead when I make the DLL (this is important as I plan to send this
out as an install and I want them to run it and forget it - not have
to change the registry manually). I can add almost all to HKLM myself
using the Advanced Tab of the AddInDesigner but the DLL fails to load
when I put LoadBehavior there.

It works for me. Here's what I did:

1. Started VB6, chose Addin for the new project
2. Removed the default form, cleared out the Connect class
3. Added the OnConnection event, with a simple MsgBox
4. Switched to the Designer form
5. Selected Microsoft Outlook in the Application
6. Set Initial Load Behavir to None
7. Switch to the Advanced tab and made the dialog wider <g>.
8. Put the following into the 'Registry Key' field:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\MyAddIn.Connect

9. Clicked 'New Value', String value, FriendlyName, My Test
10. Clicked 'New Value', DWORD value, LoadBehavior, 3
11. Noticed the 3 appeared in quotes, clicked 'Edit Value' and OK. The 3 was no longer in quotes
12. Compiled the dll
13. Started Outlook
14. Got the message
15. Popped up the COM Addins dialog, which was empty (as it should be).



Regards

Stephen Bullen
Microsoft MVP - Excel
www.BMSLtd.ie

 

[Peter Young]

I have built an add-in using VB6 for outlook. When I build the DLL it
places the registry entries automatically into HKCU as I expect. What
I want is to have the registry entries (all of them) go to HKLM
instead when I make the DLL (this is important as I plan to send this
out as an install and I want them to run it and forget it - not have
to change the registry manually).

You can use vbAdvance to customize DllRegisterServer and DllUnregisterServer. Using the RegOverridePredefKey API in
these exports should allow you to change the root key from HKCU to HKLM without having to rewrite any of the
registration code.

http://www.vbadvance.com

-Pete

 

[Ken Slovak - [MVP - Outlook]]

As a side note, always make sure an addin isn't registered in both HKLM and
HKCU. Weird things happen when it's registered in both.

 

[JvF]

Stephen-

This does what I want but it still places some entries into the HKCU
registry - Description, DisplayName and LoadBehavior (0 = None) [Those
defined on the General Page] while those I assigned in the Advanced
Tab are in HKLM - Description, DisplayName, LoadBehavior (3), Company,
Programmer et al.

Others have said don't place keys in both HKCU and HKLM but this does
- though they are different - is there a danger here?

Thanks!

 

[Peter Young]

Stephen-

This does what I want but it still places some entries into the HKCU
registry - Description, DisplayName and LoadBehavior (0 = None) [Those
defined on the General Page] while those I assigned in the Advanced
Tab are in HKLM - Description, DisplayName, LoadBehavior (3), Company,
Programmer et al.

This is because VB is adding your additional settings to the DllRegisterServer and DllUnregisterServer exports, instead
of replacing them. DllRegisterServer and DllUnregisterServer are two exported functions in every VB DLL that contain the
code that is run when the DLL is registered and unregistered. When you create an add-in using the add-in designer, VB
automatically creates the code needed to register and unregister the add-in, and any additional registry entries you
specify in the Advanced tab of the designer are added to the DllRegisterServer and DllUnregisterServer exports. VB
itself doesn't offer you any way to customize the code inside these two exports.

You have two options:

1) Use an installation package to install your add-in, but do not register the add-in DLL - instead make all the
Registry entries programatically with the installer package. The downside to this is if anyone registers your add-in DLL
manually, the wrong Registry entries will be made anyway.

2) Use vbAdvance like I mentioned before to customize the DllRegisterServer and DllUnregisterServer exports. vbAdvance
is a VB add-in that, among other things, allows you to customize DllRegisterServer and DllUnregisterServer. In order to
register your add-in to HKLM, in each of these exports, you would call the RegOverridePredefKey API to tell the OS that
anytime it sees a request for HKCU to instead use HKLM. You then call the normal registration code (easy to do as
vbAdvance doesn't eliminate it - only moves it) which does all the normal registration of your add-in. Because you've
just called RegOverridePredefKey, whenever the normal registration code tries to write to HKCU, the OS instead writes to
HKLM. This takes about a dozen lines of code to pull off. The advantage to this approach is that the Registry entries
will be made correctly when registering and unregistering the DLL - no installation package is required to make the
correct entires and there is no danger of a manual registration corrupting your installation. The downside is it'll cost
you 39 bucks to register the software (though you can try it free for 30 days). Note that when you compile a DLL with
VB, it makes it's normal Registry entries on your local machine at compile time, so if you customize DllRegisterServer,
the normal registration code gets run anyway at compile time, which can make it look like your custom reg code isn't
working. To test-register your DLL, register it on a machine you haven't registered it on before. This will give you an
accurate picture of how well it's working.

HTH,
Pete

 

[Stephen Bullen]

Hi JvF,

Others have said don't place keys in both HKCU and HKLM but this does
- though they are different - is there a danger here?

I haven't found any problems, as long as the HKCU Load behavior is zero
(None).

Regards

Stephen Bullen
Microsoft MVP - Excel
www.BMSLtd.ie