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).

On Aug 8, 12:33 pm, "Ken Slovak - [MVP - Outlook]"
wrote:

If this is managed code you might be running into the situation described inhttp://msdn2.microsoft.com/en-us/library/ms269007(vs.80).aspx#Office2....
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.