Triggering Reboots From Deferred Mode
Posted 08 August 2005 - 17:24
However, in MSI world, you are not supposed to make changes to the system except during deferred mode. Only microsoft in their infinite wisdom has made it next to impossible to keep track of state during deferred mode, because you have no ability to set properties. Additionally, the only correct ways to incur a reboot, the ForceReboot and ScheduleReboot actions, must be triggered or not based on properties.
How am I supposeed to correctly trigger a reboot as the result of something that happens during deferred execution? I find it hard to believe that the answer is you can't.
Posted 08 August 2005 - 20:08
It has other drawbacks, at that moment you cannot fail the installation. If you can predict such failures (like insufficient access), do so before InstallInitialize.
Posted 08 August 2005 - 21:50
Posted 09 August 2005 - 10:21
* When the installer is cancelled during deferred mode, the rollback sequence is entered, and you can add your own rollback CAs to undo your changes
* When the isntaller is cancelled after deferred mode, no rollback takes place, and the product remains installed anyway.
BTW this is what I meant with "you cannot fail the installation". You've got to be sure that the CA will succeed. If necessary, perform extra tests before InstallInitialize.
Posted 09 August 2005 - 17:11
Posted 09 August 2005 - 19:35
My previous suggestion is IMO quite feasible. An alternative is to install during the transaction AND include a CA afterwards, which checks that the loopback adapter was installed. This CA should compare it with previous situation (if it was installed before or not), and decide whether to force a reboot.
Obviously a lot of things can go wrong here too (failed detection, failure on reboot forcing). However I think you should not go for total perfection, so many other things can go wrong. And I've seen a lot of them: broken CDs (about 2 out of 100), broken RAM, small disk errors, corrupt Windows installations (users thinking that they can reclaim disk space by deleting System32 files, viruses), etc. etc. Weigh the risks of your solution to those chances.
Edited by Zweitze, 09 August 2005 - 19:36.
Posted 09 August 2005 - 20:15
However, if I determine a reboot is needed during the install, there seems to be NO way to alter the SetupCompleteSuccess screen depending on this. Just as a test, I've tried setting a property in a CA after InstallFinalize. The property gets set, however, anything conditioned on it in the SetupCompleteSuccess dialog fails, because the property seems to be reset when the installer goes back to the gui.
Bottom line, Microsoft dropped the ball on ability to save state throughout the install for the purposes of installation logic, if you ask me. I almost feel as if I'd have been better off writing the installer as a C++ app.
Posted 09 August 2005 - 23:08
If you do schedule the reboot after the transaction, you also cover silent installations. You are correct that properties are not transferred to the UI sequence, but for the purpose of scheduling that should not be necessary (well... maybe if you want to pass extra information to the user. I don't see an easy solution there).
Finally, the primary goal of Windows Installer is not reducing developer efforts: it is reducing adminstrator efforts. At a company I once worked for we once could sell the product to a big customer. Windows Installer did not exist then, so we had two options: 1) give 40,000 users local admin rights; 2) go to 40,000 workstations and let your admin install it. Guess what the admins of that organization advised...
Having said that, I agree with you that Deferred CAs are too restricted: I can understand that one cannot change properties, directories, feature states etc.(anything that impacts the installation) during such CAs, but requesting a reboot afterwards - I can't see that.
Posted 10 August 2005 - 15:25
Secondly, you cannot use ForceReboot after the transaction - it must be scheduled between InstallInitialize and InstallFinalize. That leaves you with schedule reboot - however ScheduleReboot will not reboot you until AFTER the SetupCompleteSuccess dialog - completely screwing you. If your last dialog is "check here to run the program you just installed", which you don't want to do if a reboot is needed, ScheduleReboot doesn't help you one iota.
Posted 11 August 2005 - 09:39
|In a C++ program you wouldn't pass a variable across functions through the registry - so why should you have to do that in your installer?|
Because this is not a C++ program. It's actually two different processes, one of them running in user context and the other in the system account. Sometimes, dropping things in the registry (or a temp file) is an easy solution for inter-process communication.
I agree that it would be nice if Windows Installer had more built in capabilities for this type of communication, but it hasn't.
Posted 11 August 2005 - 17:08
The two process problem kills you in other ways as well - for instance, installing drivers, the unsigned driver popups never come up in the foreground, because they're called from a process that has no GUI or windows.
Edited by SeanH, 11 August 2005 - 17:10.