COM registration in HKCU

[Mark J. McGinty]

Is there any way in VB to override the default self-registration code (or
the data it uses) to make it so a component registers itself in
HKEY_CURRENT_USER (HKCU) instead of HKEY_LOCAL_MACHINE (HKLM)?

If not, is there a way to expose a DLLInstall function to external callers
(that would use LoadLibrary/GetProcAddress)?

The goal here, of course, is a component that can be registered by non-admin
users. I found the
remote server option in project settings, and wrote code to make it's .VBR
file output compatible with regedit 5 (and fix the proxystub flaw) but I'm
not certain I want to depend on regedit on user's systems.

Also, the .VBR output does not include the AddIn designer class, so I had to
use the TypeLib Info component... wondering why not just do that for all
classes. It's really a pretty simple set of keys and values, esp since I
have no need to support multiple versions of the interface. I've succeeded
at performing the registration myself externally, and I suppose that is what
I will have to do...

I guess I'm just a little amazed that MS designed all this to explicitly
*require* that the intended user's security context be escalated to power
user or admin (depending on policy) in order to get an AddIn to properly
install. Even more, I'm not sure I get why COM registrations don't simply
go to HKCU by default in the first place, it would make more sense to me --
components that go in System32 should be registered system-wide, but the
rest of them? Why, to what advantage, that isn't also a disadvantage at the
same time?

TIA.

-Mark

 

[Ken Halter]

Is there any way in VB to override the default self-registration code (or
the data it uses) to make it so a component registers itself in
HKEY_CURRENT_USER (HKCU) instead of HKEY_LOCAL_MACHINE (HKLM)?

For a glimmer of hope, see:
http://groups.google.com.my/group/m...0a2cb?lnk=st&q=&rnum=2&hl=en#9394ba5e5450a2cb

 

[Mark J. McGinty]

For a glimmer of hope, see:
http://groups.google.com.my/group/m...0a2cb?lnk=st&q=&rnum=2&hl=en#9394ba5e5450a2cb

Wow! Very cool! Have you ever browsed the vbAdvance Type Library? That is
way high tech! I had no idea all that was possible with IDL.

So, Ken, thank you very much! More control over the link phase was
exactly what I was hoping for. It wasn't without challenges, but to some
extent that was because I struggled with it for a day before reading *all*
of the docs, and the sample sources.

The main problem I had, was not really a coding issue. For reasons I don't
fully understand, and in defiance of documented behavior, VB was generating
a new set of interface GUIDs every build, while set for binary
compatibility, without any source changes at all! This was a show-stopper,
since the little utility I wrote that uses the TypeLib Info component to
extract registration data depends on retaining the same registration details
for at least two consecutive builds (one to be evaluated by the util, and
the second to link-in the util's output.) It compares its generated output
to the file in which it's last output is stored -- if they differ, I have to
delete/re-import the resource and rebuild. Not only was needless
regeneration of interfaces entirely problematic, it was also spamming the
bejeebers out of my registry! (Orphaned Interface keys don't go away with
unregistration, nor do AppIDs, but that's another war story.)

It seems like it was writability of the .dsr AddIn designer file that was
driving the messed-up behavior -- a file which, I've noticed, wants to be
saved every build. I should probably try to recreate the problem again to
better understand it, but it's already cost me enough time...


So, long story short, more than just a glimmer of hope, I accomplished all
facets of my goal, if the user lacks permissions for HKCR, my AddIn will
register itself in HKCU, when registered via the usual means. All told it
took me 3 days and change to do it... time will tell if it was worth the
trouble.

Thanks again!

-Mark