Not at all - all of my add-ins are smart enought to installs themselves in
HKCU if HKLM is inaccessible :-)

If you want to register a COM object on a per-user basis, create registry
entries in
HKEY_CURRENT_USER\Software\Classes
instead of HKEY_CLASSES_ROOT

Note that when you look at HKEY_CLASSES_ROOT, Windows merges the real
HKEY_CLASSES_ROOT hive (common for all users) with the per-user entries from
HKEY_CURRENT_USER\Software\Classes.
Even if you use a function that explicitly tries to create entries in
HKEY_CLASSES_ROOT (such the the stock implementation of DllRegisterServer),
RegOverridePredefKey will allow you to redirect the calls to any registry
key of your choice for the current process completely transparently. After
you are done, you can restore the old key by calling RegOverridePredefKey
again.

Also note that most installers nowadays do not call DllRegisterServer for
the COM libraries by default (you need to expicilty tell them to do
otherwise), but simply create (what they think are) the appropriate registry
keys directly wirhout ever loading the dll during the install.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Slava Barouline" slavadotbarouline@recruitmentsystemsdotcomdotau wrote in
message ...
As a COM library it creates entries in HKLM

When I install ANY Outlook Add-in, Outlook registers Add-in in AddIns key:

HKEY_CURRENT_USER\Software\Microsoft\Office\Outloo k\AddIns\

If this is what causes my problem, every Add-in will have the same problem

Am I right?


"Dmitry Streblechenko" wrote in message
...
Might very well be if your dll tries to install itself into HKLM or HKCR.
You need to implement your own version of DllRegisterServer that uses
RegOverridePredefKey to redirect the registry output ot HKCU before the
default implementation of DllRegisterServer is called.