Office 2007, Vista, COM Add-in fails to load if UAC is turned off

[eselk]

When I use the Add... button from the COM add-ins list to add my DLL,
I can see that Outlook loads the DLL and calls DllRegisterServer, and
everything suceeds as expected. However, Outlook then unloads my DLL
(which I think it normally does after registering it), but then it
never loads my DLL again (DllEntryPoint never called). My COM add-in
shows up in the list AND IS CHECKED, but is not actually loaded. If I
close the list and re-open, it is not checked anymore and Outlook says
it had a run-time error at startup. However, it never loaded my DLL
again. My DLL doesn't have any non-system dependencies so I don't
think it is a missing DLL issue (they are all located in system32).

Weird thing is, the same DLL works fine if I enable UAC. Same DLL
also works under other versions of Windows and Office. I know the
easy answer would be to just enable UAC, but that is beyond my control
since it isn't just an in-house project.

Outlook still doesn't require add-ins to be signed, right? I'm
thinking my add-in may not be registered correctly, maybe there are
some new settings as of Office 2007... although why would it work with
UAC enabled, if it was just that.

 

[Ken Slovak - [MVP - Outlook]]

Not enough information.

Managed code or non-managed code? VSTO or shimmed shared addin if managed
code?

Where is the addin being registered, HKCU or HKLM?

If this is managed code you might be running into the situation described in
http://msdn2.microsoft.com/en-us/library/ms269007(vs.80).aspx#Office2003Vista.
The relevant part might be this:

Registry Entries for Microsoft Office 2003 Add-ins on Windows Vista
If you are deploying a Microsoft Office 2003 add-in to a computer that is
running Windows Vista, you must create several of the registry keys in a
different registry subtree in the following scenarios:

a.. The user is running the Microsoft Office 2003 application with a full
administrator access token.

- or -

b.. The user has turned off User Account Control (UAC).

In these scenarios, you must create the COM registration keys (that is, all
of the keys that are defined under HKEY_CURRENT_USER\Software\Classes) under
HKEY_LOCAL_MACHINE\Software\Classes instead. This is because Windows Vista
looks for COM registration keys only under HKEY_LOCAL_MACHINE in these
scenarios. For information about how to change the registry keys in the
default Setup project, see Setup Projects for Application-Level Add-ins.

Note
Do not move the registry keys that are under
HKEY_CURRENT_USER\Software\Microsoft in these scenarios.

 

[eselk]

Not using managed code, just C++, but this is exactly what I needed.
I didn't know that part at the end... I just figured it was best to
register under HKEY_CURRENT_USER (for the classes part), since Vista
put a big hex on anything HKEY_LOCAL_MACHINE. I don't like the idea
of registering under current_user if not running UAC, and
local_machine if running UAC, so I think I'll just always do
local_machine (which for me means I have to shell out to another EXE
to elevate, because my main install/setup isn't elevated, what fun).