This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: ScheduleReboot and chained packages
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 03, 2010
06:21 PM
ScheduleReboot and chained packages
Hello,
Does anyone know how to make chaining work when the parent installer needs a reboot? I haven't found anything for this case.
Here are the details:
I have an IS2010 Basic MSI project that chains another Basic msi package. In 99% of the cases this works fine, but on one dev system the device driver binary that gets installed with the parent MSI is locked and the ScheduleReboot action is triggered. When this happens, the chained install is skipped. No error will be thrown. From the MS documentation I can see that this is expected. But what am I supposed to do in this case? I guess in theory any install could run into a locked file at one stage although usually it doesn't. Doesn't that mean chaining is unusable if you want a bulletproof install?
Hmm, I'm puzzled here. What am I overlooking? Any ideas?
Sandra
Does anyone know how to make chaining work when the parent installer needs a reboot? I haven't found anything for this case.
Here are the details:
I have an IS2010 Basic MSI project that chains another Basic msi package. In 99% of the cases this works fine, but on one dev system the device driver binary that gets installed with the parent MSI is locked and the ScheduleReboot action is triggered. When this happens, the chained install is skipped. No error will be thrown. From the MS documentation I can see that this is expected. But what am I supposed to do in this case? I guess in theory any install could run into a locked file at one stage although usually it doesn't. Doesn't that mean chaining is unusable if you want a bulletproof install?
Hmm, I'm puzzled here. What am I overlooking? Any ideas?
Sandra
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 09, 2010
10:41 AM
Hi Sandra,
Did u manage to make a chained msi?, i´m trying to but failed many times, can u tell how u did´t?
Thanks.
Did u manage to make a chained msi?, i´m trying to but failed many times, can u tell how u did´t?
Thanks.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 09, 2010
05:58 PM
Hi,
what exactly doesn't work? I didnt' have any other problems than the one mentioned in the post when following the instructions given here:
http://helpnet.flexerasoftware.com/Robo/BIN/Robo.dll?tpc=/robo/projects/installshield16helplib/ChainerAdding.htm
My project is a BasicMSI in IS 2010 and only meant for Windows 7.
-Sandra
what exactly doesn't work? I didnt' have any other problems than the one mentioned in the post when following the instructions given here:
http://helpnet.flexerasoftware.com/Robo/BIN/Robo.dll?tpc=/robo/projects/installshield16helplib/ChainerAdding.htm
My project is a BasicMSI in IS 2010 and only meant for Windows 7.
-Sandra
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 10, 2010
01:12 PM
just in case anyone is interested. I was able to make the chained package successfully install after the reboot with the help of two custom actions.
1) Immediate Execution set Property CA to save the value of IS_CHAINER_POST_COMMANDLINE
2) Deferred in System Context InstallScript CA that parses the CustomActionData and does the following with the value:
- copy the msi into temp folder
- bring the parameters into the right format for an msiexec call
- create a registry value with the msiexec call under RunOnce to make the install start after the next reboot
both CA's are conditioned so that they only run in when there is a chained package to be installed and a reboot detected.
For now this is not gone through QA yet, it's just in a proof of concept MSI and only ran on Windows 7 32Bit.
OPEN QUESTION
----------------
The one problem I still have with this is, why isn't the MSIEngine or InstallShield itself doing this for me? I can't imagine they just 'forgot' about this case. Is there anything in the system that I screw up when forcing the chained package to install after the reboot? In which scenario could this fail?
Any ideas are appreciated.
Thanks,
Sandra
1) Immediate Execution set Property CA to save the value of IS_CHAINER_POST_COMMANDLINE
2) Deferred in System Context InstallScript CA that parses the CustomActionData and does the following with the value:
- copy the msi into temp folder
- bring the parameters into the right format for an msiexec call
- create a registry value with the msiexec call under RunOnce to make the install start after the next reboot
both CA's are conditioned so that they only run in when there is a chained package to be installed and a reboot detected.
For now this is not gone through QA yet, it's just in a proof of concept MSI and only ran on Windows 7 32Bit.
OPEN QUESTION
----------------
The one problem I still have with this is, why isn't the MSIEngine or InstallShield itself doing this for me? I can't imagine they just 'forgot' about this case. Is there anything in the system that I screw up when forcing the chained package to install after the reboot? In which scenario could this fail?
Any ideas are appreciated.
Thanks,
Sandra
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 11, 2010
11:26 AM
Reading between the lines a little bit, I think the reason Windows Installer disallows this is that transactions do not survive reboots. Since chaining is intended to merge multiple package installations (or uninstallations) into a single transaction (its real name is Multiple Package Transaction), Windows Installer just gives up in this case. There are other possible reasons one can infer—perhaps they didn't get multiple package's post-reboot operations into their test matrix—but it's unclear.
I do think your workaround for this limitation sounds pretty good on the surface, and aside from the separate transactions part, I hope there's no big reason it would fail. It's unclear to me whether it's better to parse the IS_CHAINER_POST_COMMANDLINE property, or to process the ISChainPackage and ISChainPackageData tables yourself, so go with what works.
I do think your workaround for this limitation sounds pretty good on the surface, and aside from the separate transactions part, I hope there's no big reason it would fail. It's unclear to me whether it's better to parse the IS_CHAINER_POST_COMMANDLINE property, or to process the ISChainPackage and ISChainPackageData tables yourself, so go with what works.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 23, 2010
11:52 AM
I have the same issue as SMadden (except on XP - haven't tested other OSs yet), and really appreciate the insight (thanks Sandra!).
In my case, the initial install works correctly, but the major upgrade of the primary product does not update the chained MSIs. I have 2 chained MSIs, and I can see in the log that one chained MSI is skipped because it has not changed from the initial install (this is fine), and the second MSI seems to be queued for install ("Marking chained package DMSetup for installation"), but is not updated to the new version.
I've also observed strange behavior on uninstall - I am prompted to restart (although none of the files installed are in use?!?!), and if I say Yes to restart, the chained MSIs are not removed; if I do NOT accept the restart, the chained MSIs are processed and uninstalled correctly immediately afterwards!
I would love to see exactly how Sandra's CAs are sequenced, coded and conditioned, in hopes that it will work for me too. Any chance Sandra could share these details? Thanks.
- Matt -
In my case, the initial install works correctly, but the major upgrade of the primary product does not update the chained MSIs. I have 2 chained MSIs, and I can see in the log that one chained MSI is skipped because it has not changed from the initial install (this is fine), and the second MSI seems to be queued for install ("Marking chained package DMSetup for installation"), but is not updated to the new version.
I've also observed strange behavior on uninstall - I am prompted to restart (although none of the files installed are in use?!?!), and if I say Yes to restart, the chained MSIs are not removed; if I do NOT accept the restart, the chained MSIs are processed and uninstalled correctly immediately afterwards!
I would love to see exactly how Sandra's CAs are sequenced, coded and conditioned, in hopes that it will work for me too. Any chance Sandra could share these details? Thanks.
- Matt -
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 24, 2010
06:14 PM
Hi Matt,
Upfront, I had to change the code a bit in the MSI that goes out to customers compared to the proof of concept one that I described in an earlier post. I don't want to go into details here why, I'll just describe what worked.
We needed 4 different custom actions, all scheduled in a row with different In-Script Executions. The first two save the value of IS_CHAINER_POST_COMMANDLINE as CustomActionData for the last 2 CAs. From IS_CHAINER_POST_COMMANDLINE you can find out where the chained packages are temporarily extracted to and how they are called.
The 3rd CA saves a copy of the chained installer in a temp folder because the original will have been cleaned up by the time you need it. It does this by parsing the CustomActionData for the installers name and location, gets the %TEMP% folder location and copies it.
The 4th CA makes sure that the chained package is not already installed on the system (MsiEnumRelatedProducts) and if not, extracts the calling parameters from the CustomActionData and creates a registry value under RunOnce to run the installer incl. parameters after the reboot.
1st and 2nd CA:
- MSI Type 51 (Set a Property)
- In-Script Execution: Immediate
- Scheduled in the Execute Sequence after Schedule Reboot and before InstallFinalize
- Property Name: PrecopyChainedPackages and LaunchChainedPackages
- Property Value: [IS_CHAINER_POST_COMMANDLINE]
3rd CA:
- Name: PrecopyChainedPackages
- MSI Type 68672 (InstallScript code)
- In-Script Execution: Deferred in System Context
- Scheduled in the Execute Sequence after 2nd CA
4th CA:
- Name: LaunchChainedPackages
- MSI Type 69184 (InstallScript code)
- In-Script Execution: Commit in System Context
- Scheduled in the Execute Sequence after 3rd CA
Hope this helps you a little. You might also want to look into processing the ISChainPackage and ISChainPackageData tables like Michael suggested instead of parsing IS_CHAINER_POST_COMMANDLINE. It might be easier, I don't know. I didn't try since I had the parsing stuff working already when he mentioned it.
-Sandra
Upfront, I had to change the code a bit in the MSI that goes out to customers compared to the proof of concept one that I described in an earlier post. I don't want to go into details here why, I'll just describe what worked.
We needed 4 different custom actions, all scheduled in a row with different In-Script Executions. The first two save the value of IS_CHAINER_POST_COMMANDLINE as CustomActionData for the last 2 CAs. From IS_CHAINER_POST_COMMANDLINE you can find out where the chained packages are temporarily extracted to and how they are called.
The 3rd CA saves a copy of the chained installer in a temp folder because the original will have been cleaned up by the time you need it. It does this by parsing the CustomActionData for the installers name and location, gets the %TEMP% folder location and copies it.
The 4th CA makes sure that the chained package is not already installed on the system (MsiEnumRelatedProducts) and if not, extracts the calling parameters from the CustomActionData and creates a registry value under RunOnce to run the installer incl. parameters after the reboot.
1st and 2nd CA:
- MSI Type 51 (Set a Property)
- In-Script Execution: Immediate
- Scheduled in the Execute Sequence after Schedule Reboot and before InstallFinalize
- Property Name: PrecopyChainedPackages and LaunchChainedPackages
- Property Value: [IS_CHAINER_POST_COMMANDLINE]
3rd CA:
- Name: PrecopyChainedPackages
- MSI Type 68672 (InstallScript code)
- In-Script Execution: Deferred in System Context
- Scheduled in the Execute Sequence after 2nd CA
4th CA:
- Name: LaunchChainedPackages
- MSI Type 69184 (InstallScript code)
- In-Script Execution: Commit in System Context
- Scheduled in the Execute Sequence after 3rd CA
Hope this helps you a little. You might also want to look into processing the ISChainPackage and ISChainPackageData tables like Michael suggested instead of parsing IS_CHAINER_POST_COMMANDLINE. It might be easier, I don't know. I didn't try since I had the parsing stuff working already when he mentioned it.
-Sandra
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 24, 2010
06:33 PM
Hi Sandra,
Thanks so much for taking the time to reply so completely - YOU ROCK!!
- Matt -
Thanks so much for taking the time to reply so completely - YOU ROCK!!
- Matt -
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)