Key Path...

I am new to packaging and am working with one of the more difficult msi's, Palm Desktop. Per suggestions in the packages section, I've moved all of the HKCU entries to a new component. However, I have a question about the key path:

It was my understanding that you only need 1 key path per component. With this one key path missing, the MSI will repair all of the Subkeys present in that component when it goes through the repair process. However, when I pick a random key from the component, after the repair process it only has created some of the necessary registry subkeys in that component, not all. However, if I edit the MST and add a second key path for the registry key which is not being created, it works fine. DO YOU NEED A KEY PATH FOR EACH REGISTRY SUBKEY?

0 Comments   [ + ] Show comments

Answers (3)

Posted by: meastaugh1 14 years ago
Senior Purple Belt
How is your MSI organised in terms of features? I believe it's best practice to have all your current user registry keys in an overall parent feature. The result is that when an entry point is invoked in a child feature, the components in the (CU) parent feature will be checked and repaired.

In your current configuration, do you see windows installer activity when a user launches the application via the advertised entry point? Do all the CU registry entries belong to the same component?

I think this diagram gives a good idea of repair.
Posted by: tyanni 14 years ago
Yellow Belt
I am using a MST and have moved all of the HKCU entries from the components to one component, called CurrentUser. I've then organized the MSI as so:

CurrentUser (Feature)
--Current User (Component
--Feature 1
--Feature 2

Additionally, I've set the shortcut to Palm.exe on the start menu to be an advertised shortcut. When I launch the shortcut as a different user than the msi was installed as, Windows goes through the repair process. HOWEVER, the problem is, as stated in my first post, is that it doesn't create all of the necessary reg keys, just some of them.

Posted by: revizor 14 years ago
Third Degree Blue Belt
I recall seeing precautions against rearranging the feature structure using MSTs. Anyway, is there a chance that your key component may be part of several features? This way, it may be restored as part of a different feature, so by the time when your intended key path is checked, the key component already exists?
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ