Include Settings in Vendor .MSI
Hello everyone!
I'am trying to include custom settings made in the HKCU Hive into the vendor .msi of Adobe Reader 7.0. As far as I know you just have to create a top level feature and a component in that feature and ad the keys. Then you have to make this feature the parent of all other features, so the component in that feature(containing the HKCU Keys) will only get a component repair when windows installer checks his keypaths because it is located above all features that might have entry points. The benefit of this is that windows installer does'nt need the softwaresource to repair regkeys(it uses the cached .msi). Well in the past this worked fine for me, but now windows installer also wants to reinstall the entry point component(containing the shortcut) even though the keypath points directly to AcroRdr32.exe and I am absolutly sure it's there. Another phenomenon is that if everything works fine as mentioned before msiexec(source is not needed) generates 2 messages in the eventlog:
1. The first containing the guids of the product, the missing top level feature and the component containing the regkeys.
2. The other containing the guid of the product, the entrypointfeature the led to the missing keypaths and now surprise NO COMPONENT GUID! it's just left in empty brackets. Example:
Detection of product {dslfkjsdj} and feature {asdjhs} failed for component "".
In my opinion this is just an explanation that nothing has gone wrong in the entrypoint feature, meaning all the keypaths are there but it just triggered a component level repair in the higher features and thats the reason why windows installer can't tell the components guid in this case.
In the case of my adobe acrobat reader problem this is NOT the case! The component guid is listed in the second message!
I know I can work around this by using active setup but i just don't want to!
I am running out of ideas please help me anyone!
I'am trying to include custom settings made in the HKCU Hive into the vendor .msi of Adobe Reader 7.0. As far as I know you just have to create a top level feature and a component in that feature and ad the keys. Then you have to make this feature the parent of all other features, so the component in that feature(containing the HKCU Keys) will only get a component repair when windows installer checks his keypaths because it is located above all features that might have entry points. The benefit of this is that windows installer does'nt need the softwaresource to repair regkeys(it uses the cached .msi). Well in the past this worked fine for me, but now windows installer also wants to reinstall the entry point component(containing the shortcut) even though the keypath points directly to AcroRdr32.exe and I am absolutly sure it's there. Another phenomenon is that if everything works fine as mentioned before msiexec(source is not needed) generates 2 messages in the eventlog:
1. The first containing the guids of the product, the missing top level feature and the component containing the regkeys.
2. The other containing the guid of the product, the entrypointfeature the led to the missing keypaths and now surprise NO COMPONENT GUID! it's just left in empty brackets. Example:
Detection of product {dslfkjsdj} and feature {asdjhs} failed for component "".
In my opinion this is just an explanation that nothing has gone wrong in the entrypoint feature, meaning all the keypaths are there but it just triggered a component level repair in the higher features and thats the reason why windows installer can't tell the components guid in this case.
In the case of my adobe acrobat reader problem this is NOT the case! The component guid is listed in the second message!
I know I can work around this by using active setup but i just don't want to!
I am running out of ideas please help me anyone!
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
WiseUser
19 years ago
It is my understanding that the entire "entry point" feature is always repaired. And other features (including parent features with broken components) only receive a "component-level" repair.
This is why "Wise" products create a large top level "Complete" feature, and small "entry point" sub-features.
Hope this helps?
Edit: How many components are in your entry-level feature?
This is why "Wise" products create a large top level "Complete" feature, and small "entry point" sub-features.
Hope this helps?
Posted by:
sini
19 years ago
I know! I am also using Wise Package Studio to repackage my Apps! But if things run like you said, then the msi would need the source everytime, as the entrypoint is always bound to some sort of .dll or .exe!
But anyway thx for your help!
But anyway thx for your help!
Posted by:
WiseUser
19 years ago
ORIGINAL: sini
I know! I am also using Wise Package Studio to repackage my Apps! But if things run like you said, then the msi would need the source everytime, as the entrypoint is always bound to some sort of .dll or .exe!
But anyway thx for your help!
Not true I'm afraid...
The repair uses a REINSTALLMODE of "o" for files not "a". As long as the file is versionned or has an MsiFileHash table entry there should be no need for the source.[;)]
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.