Why does Regasm put ProgId into HKEY_CURRENT_USER?

问题:

I have two Virtual Machines that I wish to (Wix) install my software onto. One is Windows XP SP2 and another is Windows XP SP1. Neither of them use domains, and both of them have the local user Administrator with admin privileges.

Running RegAsm.exe to register MyApp.dll on the machine with SP3 puts my ProgId in the folders:

HKEY_CLASSES_ROOT\MyAppProgId

HKEY_LOCAL_MACHINE\Software\Classes\MyAppProgId

whereas running it on the SP2 machine puts it in the folders:

HKEY_CLASSES_ROOT\MyAppProgId

HKEY_CURRENT_USER\Software\Classes\MyAppProgId

I found this while trying to load MyApp.dll from a service. The registry file generated from RegAsm.exe and also Heat.exe both appear to be updating HKEY_CLASSES_ROOT.

Does anyone know what could cause this?

EDIT: I ended up getting around this by writing directly to HKEY_LOCAL_MACHINE instead of HKCR - this involved manually editing a generated .reg file or .wxs file.

回答1:

On older setups HKEY_LOCAL_MACHINE is writable for a normal user, on newer Windows's (e.g. Windows 7) it is not. Might depend on configuration, user account type etc.

Registered classes go either to HKEY_LOCAL_MACHINE\SOFTWARE\Classes (sometimes writable, as mentioned) or HKEY_CURRENT_USER\Software\Classes (always writable). Both work. The first case is the overwhelming default.

HKEY_CLASSES_ROOT is actually only a view, which merges the contents of the aforementioned branches. This is why you see it under two different locations.

RegAsm seems to be smart enough to detect the readonly condition of HKLM and automagically picks HKCU instead. Or there is some configuration setting which differs between your VMs.

The main difference is that in the second case, the dll is only usable under the user account where you registered it. Your service probably runs under another account, so it cannot load the dll on the 2nd machine.