One of the component rules is "HKLM & HKCU should not be together" in application repackaging. What is the logic behind it.Please Explain.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Answers

1
From past experience this ends up with the MSI exploding and causing physical damage to the PC, especially the registry...  :D

The reason is due to to HKCU and HKLM machine paths being in different places (think multi user PC's). You don't want Windows Installer repairing the HKLM every time if finds something missing in the HKCU - remember the component will contain registry and files.

*thats if you have the KeyPath set in the HKCU space.

There's probably a better answer which you can read up on MSDN.

Basicly, just don't do it.
Answered 08/07/2016 by: rileyz
Red Belt

Please log in to comment
1

If your component has HKLM and HKCU keys one of them (but only one) will be the key path.

If it is the HKLM key then after the s/w is installed HKLM and HKCU keys will be set but the HKCU key is only set for the person who installed the app. When another user (not the installer) starts the app the test on the key file will cause the writing of the HKCU key to be skipped as the HKLM key already exists.

If the HKCU key is the key path then each time a user starts the app for the first time, the HKCU key which is the key path doesn't exist so it and the HKLM key will get re-written causing a UAC activation if that user isn't an admin. It's a problem where an admin installs software for a non-admin user and it breaks ICE57.

Answered 08/09/2016 by: olditguy
Second Degree Blue Belt

Please log in to comment
0

agree with both of the above answers.

You need to keep machine and user stuff separately. Its just one of the rules.

Its a very similar reason as to why a component with a user file has to have a key path of an HKCU.

 

Answered 08/14/2016 by: Badger
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity