Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Triggering Reboots From Deferred Mode


10 replies to this topic

SeanH

SeanH
  • Members
  • 21 posts

Posted 08 August 2005 - 17:24

After moving from an InstallShield to a pure MSI based installer, I'm starting to see some serious drawbacks. My setup needs to install a loopback adapter during setup. This may, or may not require a reboot. You are informed of the requirement when you make the calls to do the installation.

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.

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 08 August 2005 - 20:08

You can also make changes to the system *after* deferred mode, meaning after InstallFinalize. At that moment, you have normal access to the installer and its properties.
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.

SeanH

SeanH
  • Members
  • 21 posts

Posted 08 August 2005 - 21:50

by that logic, i could make changes to the system before deferred mode as well. The whole point of making changes, in my case, installing a loopback adapter, during deferred mode is that rollback can occur properly, and the changes are applied as a transaction. If my custom action encounters a problem, and it is occuring after installvalidate, where does that leave the users system?

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 09 August 2005 - 10:21

* When the installer is cancelled before 'deferred mode', no rollback takes place, so you should not change the target system before this deferred mode.
* 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.

SeanH

SeanH
  • Members
  • 21 posts

Posted 09 August 2005 - 17:11

you should never assume a function will "always succeed". If you think your code is perfect, and failure conditions will never happen, you're fooling yourself. it is for those reasons that I do not wish to install a loopback adapter during any time but deferred execution mode, and therein lies my problem.

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 09 August 2005 - 19:35

You are totally correct - it is not guaranteed to be foolproof. But you are fooling yourself to think you can guarantee an install to your specs: what stops a customer to fire up Orca, edit your msi and break the install?
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.


SeanH

SeanH
  • Members
  • 21 posts

Posted 09 August 2005 - 20:15

i think you're missing what I'm geting at. I don't need to determine IF the adapter got installed or not. The calls you make to install it let you know if a reboot is, or isn't, required. This obviously affects how the last screen should look - you would either get an option to start the program, or an option to reboot.

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.

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 09 August 2005 - 23:08

I wasn't clear enough. During the transaction you install the adapter, if you detect that a reboot is required, you leave a mark somewhere (like the registry). After the transaction, your second CA should see if the mark is there, in that case force a reboot.
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.

SeanH

SeanH
  • Members
  • 21 posts

Posted 10 August 2005 - 15:25

I had come up with the "marker" idea as well. First of all, using markers in the registry or elsewhere really is a bad practice, as it potentially allows you to leave things on the computer unintentionally that have no purpose. 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?

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.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 11 August 2005 - 09:39

QUOTE
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.

SeanH

SeanH
  • Members
  • 21 posts

Posted 11 August 2005 - 17:08

I understand the difficulty arises from the two process nature of Windows Installer. To me, this indicates a poor design decision. Especially if Microsoft has any interest in moving people away from using the (imho) horribly crappy InstallScript mechanism, the difficulty in tracking state was a major mess up. Countless times I had to explain to someone a difficulty in making our new installer work, and they'd respond, "that was easy with InstallShield - why should it be hard now?"

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.