Remote DLL Registration without access to HKEY_CLASSES_ROOT

We have a legacy VB6 application that updates itself on startup by pulling down the latest files and registering the COM components. This works for both local (regsvr32) ActiveX COM Components and remote (clireg32) ActiveX COM components registered in COM+ on another machine.

New requirements are preventing us from writing to HKEY_LOCAL_MACHINE (HKLM) for security reasons, which is what obviously happens by default when calling regsvr32 and clireg32.

We have come up with an way to register the local COM component under HKEY_CURRENT_USER\Software\开发者_JAVA技巧Classes (HKCU) using the RegOverridePredefKey Windows API method. This works by redirecting the inserts into the registry to the HKCU location. Then when the COM components are instantiated, windows first looks to HKCU before looking for component information in HKLM. This replaces what regsvr32 is doing.

The problem we are experiencing at this time is when we attempt to register VBR / TLB using clireg32, this registration process also adds registration keys to HKEY_LOACL_MACHINE.

Is there a way to redirect clireg32.exe to register component is HKEY_CURRENT_USER? Are there any other methods that would allow us to register these COM+ components on clients machine with limited security access?

Our only solution at this time would be to manually write the registration information to the registry, but that is not ideal and would be a maint issue.

---

I see few happy answers here. The notion of an app using 12 year old technology needing to install updates is an odd one and just not well supported on modern machines. A common solution like reg-free COM is out, I think, not compatible with COM+. It is also pretty strange that a bug-fix style update would need to re-register components. Have you verified that this is actually required?

Extending on that theme, how often do you actually change GUIDs in deployments? Taking charge of the registration yourself rather than leaving it up to the components themselves should be workable when the keys don't constantly change. Could be as easy as capturing the registration with SysInternals' ProcMon utility, compose a .reg file that sets HKCU keys instead.

Beyond that, you really do need to gain the right to registry keys that are not writable. If you can't get the okay from the customer then consider asking for a scheduled task that installs updates. They can get access, provided the sys admin allows it.