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?
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)
Please log in to answer
Posted by:
meastaugh1
18 years ago
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.
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
18 years ago
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
--etc...
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.
Tim
CurrentUser (Feature)
--Current User (Component
--Feature 1
--Feature 2
--etc...
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.
Tim
Posted by:
revizor
18 years ago
Tyanni,
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?
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.