Self Healing
Hello everyone!
I am currently packaging PowerTerm525 which is a very simple and old app. However I am trying to populate a HKCU setting through SelfHealing which sets the AppCompatibility Mode to W2K.
MSI Structure:
Toplevelfeature is Complete containing only the HKCU Component. Childfeature is Feature1 containing all the Files Components(there all in a single directory) and the Shortcut to pwt525.exe. As far as I know the Shortcutentrypoint will trigger a componentlevel selfrepair of the HKCU Component(the reason is that feature Complete is located above the entrypointfeature) because the keypath is missing(so far so good). But then msiexec prompts for the source! How can this be? Ideas anyone? The machine is running a clean XP, which means the WindowsInstaller2.0 requirement for this feature is surely guaranteed!
P.S.: The question is this: Sometimes windows installer needs the original source to populate the HKCU entrys and sometimes not(although the cached .msi is always there, and the structure of the .msi is always the same). Everyone who can answer me this question shall be my hero of the day!
I am currently packaging PowerTerm525 which is a very simple and old app. However I am trying to populate a HKCU setting through SelfHealing which sets the AppCompatibility Mode to W2K.
MSI Structure:
Toplevelfeature is Complete containing only the HKCU Component. Childfeature is Feature1 containing all the Files Components(there all in a single directory) and the Shortcut to pwt525.exe. As far as I know the Shortcutentrypoint will trigger a componentlevel selfrepair of the HKCU Component(the reason is that feature Complete is located above the entrypointfeature) because the keypath is missing(so far so good). But then msiexec prompts for the source! How can this be? Ideas anyone? The machine is running a clean XP, which means the WindowsInstaller2.0 requirement for this feature is surely guaranteed!
P.S.: The question is this: Sometimes windows installer needs the original source to populate the HKCU entrys and sometimes not(although the cached .msi is always there, and the structure of the .msi is always the same). Everyone who can answer me this question shall be my hero of the day!
0 Comments
[ + ] Show comments
Answers (10)
Please log in to answer
Posted by:
sini
19 years ago
To everyone who has ever had the same problem the solution is to create a single feature for every component that has an entrypoint and move all other components to Complete. In my case I had to move every component exept the pwt525.exe component(which contains the shortcut - the entry point) to complete. The result is the same the user won't need administratorrights in both cases but in this he won't need the source!
Posted by:
WiseUser
19 years ago
Have you still not worked out the whole MSI self-repair thing? It's not really all that complicated. Check back to one of your previous posts for clues...
http://itninja.com/question/include-settings-in-vendor-.msi&mpage=1&key=component+level⨃
Heres an explanation of your symptoms...
1) When you had all your components under the child feature ("Feature1"), the broken "CurrentUser" component was leading to a component-level repair of the top level feature ("Complete") AND a feature-level repair of the entry-point feature ("Feature1"). Something in your MSI (probably an unversioned file) caused the source to be required in order to fix one of the components within the "entry-point" feature ("Feature1"). A log file would reveal which resource(s) was causing the problem.
2) When you moved all but one of your components back into the "Complete" feature (the default "Wise" structure), you prevented the source requirement because the component that had been causing the problem is no longer being repaired because it's containing feature ("Complete") only receives a component-level repair. A component-level repair will only repair a component if it's keypath is missing.
I hope this clarifies thigs for you? Otherwise never mind - it might help someone else at a later date.
http://itninja.com/question/include-settings-in-vendor-.msi&mpage=1&key=component+level⨃
Heres an explanation of your symptoms...
1) When you had all your components under the child feature ("Feature1"), the broken "CurrentUser" component was leading to a component-level repair of the top level feature ("Complete") AND a feature-level repair of the entry-point feature ("Feature1"). Something in your MSI (probably an unversioned file) caused the source to be required in order to fix one of the components within the "entry-point" feature ("Feature1"). A log file would reveal which resource(s) was causing the problem.
2) When you moved all but one of your components back into the "Complete" feature (the default "Wise" structure), you prevented the source requirement because the component that had been causing the problem is no longer being repaired because it's containing feature ("Complete") only receives a component-level repair. A component-level repair will only repair a component if it's keypath is missing.
I hope this clarifies thigs for you? Otherwise never mind - it might help someone else at a later date.
Posted by:
sini
19 years ago
Ok, then why doesn't the stupid wininstaller tell me what caused the featurelevel repair of feature1, he obviously can tell me if it's a component repair(component currentuser resource blabla.. missing). In the case of a featurelevelrepair he just tells me the component guid of the entrypoint, that triggered the repair but not that like u said "component XXXX containing unversioned file ... whatever" caused the repair!
Posted by:
WiseUser
19 years ago
If the Installer logged everything it did in the event log, there'd be nothing but MSI information in the logs.
The installer will log the information that you want, but it will do so in a log file - simply enable logging through policy.
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\Logging" (use "icewarmupv" as a value)
The log file will be created in your %temp% folder. Look for phrases like "Executing op: FileCopy" or "no source file hash provided to compare".
The installer will log the information that you want, but it will do so in a log file - simply enable logging through policy.
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\Logging" (use "icewarmupv" as a value)
The log file will be created in your %temp% folder. Look for phrases like "Executing op: FileCopy" or "no source file hash provided to compare".
Posted by:
akhlaque
19 years ago
Posted by:
WiseUser
19 years ago
The following was copied and pasted from the SDK...
Writes logging information into a logfile at the specified path. Flags indicate which information to log. If no flags are specified, the default is 'iwearmo.'
i - Status messages.
w - Nonfatal warnings.
e - All error messages.
a - Start up of actions.
r - Action-specific records.
u - User requests.
c - Initial UI parameters.
m - Out-of-memory or fatal exit information.
o - Out-of-disk-space messages.
p - Terminal properties.
v - Verbose output.
x - Extra debugging information. Only available on Windows Server 2003.
+ - Append to existing file.
! - Flush each line to the log.
"*" - Wildcard, log all information except for the v and x options. To include the v and x options, specify "/l*vx".
i - Status messages.
w - Nonfatal warnings.
e - All error messages.
a - Start up of actions.
r - Action-specific records.
u - User requests.
c - Initial UI parameters.
m - Out-of-memory or fatal exit information.
o - Out-of-disk-space messages.
p - Terminal properties.
v - Verbose output.
x - Extra debugging information. Only available on Windows Server 2003.
+ - Append to existing file.
! - Flush each line to the log.
"*" - Wildcard, log all information except for the v and x options. To include the v and x options, specify "/l*vx".
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.