I take It all back:using Windows Installer (MSI) Rollback Actions

Source: Internet
Author: User

Original Link: http://blogs.flexerasoftware.com/installtalk/2011/10/ I-take-it-all-back-using-windows-installer-msi-rollback-actions.html#sthash. Kiiukl0s.dpuf

by Robert Dickau

Sometimes an installer just needs to does something that Windows installer doesn ' t normally do. When that's happens, it's a simple matter of writing a custom action, right? Unfortunately, it ' s not so simple. In this post, we'll look at techniques for reversing changes made by a custom action.

When you launch a installation, it first runs in what ' s called immediate mode or script-generation mode. As your installer runs in this immediate mode, it generates an internal to-do list of what it would do on a system-"first I ' ll install files, then I'll create shortcuts, then I'll write to the registry, and then ... "-but doesn ' t yet make any Syst EM changes.

After immediate mode is do, your installer then switches to something called deferred mode or script-execution mode. In deferred mode, your installer performs the actions listed in this script: "Now I'm installing files, now I ' m creating s Hortcuts, now I ' m writing to the registry, and now I ' M ... " (The internal to-do list, or script, is a fixed at this point, which is so you can ' t set property values outside of Immedia Te mode, for example).

As your installer runs in deferred mode, it simultaneously creates a rollback script describing how to undo changes mad E by the standard actions. While the installer installs files, for example, it adds to the rollback script specific information about what it would h Ave-to-do-get-the-system back-to-its-pre-installer state: "To get the system back to how it is, I ' d need to remove Sam Ple.exe and Readme.txt, and also restore the original version of Sample.dll that I replaced. " (Windows Installer would also temporarily hold on to resources such as files, it needs to restore in case of rollback.) If the installer runs to completion, the rollback script and any cached resources is deleted. But if the installation encounters a fatal error, or if the user cancels the installation during deferred mode, the Rollba CK script runs.

A big reason to use standard Windows Installer actions instead of custom actions are that standard actions handle their own Cleanup during uninstallation or rollback. When you use a custom action, Windows Installer have no idea what the executable, DLL, InstallScript, etc., so you used D ID to the system, and therefore have no idea how to roll back the changes the custom action made. If your deferred custom action makes any system changes, you should create a corresponding rollback action.

Immediate mode actions don ' t write to the rollback script, which means that immediate-mode actions, then make system change S won ' t get rolled back if the installation fails. This is one of the several reasons not-to-make system changes during immediate mode

(Bonus grammar tip:the noun and adjective are one word, rollback, while the verb is a and words, roll back. "If my rollback action runs, it'll roll back my changes." An easy trick are to see if it's appropriate to form the past tense by Adding-ed:you ' d say ' rolled back ', not ' rollbacked ", and the present tense would be the same number of words. Same goes for cleanup vs. clean up, setup vs. set up, and so on. anyway.)

With InstallShield, your mark a custom action as being a rollback action using its in-script execution setting.

Because The rollback script is created as deferred execution are taking place, and not beforehand, a rollback action must b E placed in the Execute sequence before the action it rolls back. (Anywhere before the action being rolled back was fine, but for readability's sake and other reasons, placing the rollback Action immediately before the action it rolls back seems to work best.) If you write a deferred custom action called "Changesomething", its corresponding rollback action "changesomethingback" sh Ould appear in the sequences immediately before it.

Double Negatives

Things start to get confusing with uninstallation custom actions. Without a condition, an action all runs, both during the initial installation as well as maintenance mode, including a Complete uninstallation. By setting a condition in an action, you can specify during which modes it should run:  not installed  for the initial installation,  remove= ' all '  for complete uninstallation, and so on.

The same holds for rollback actions. If you had a deferred action that makes system changes during the initial installation, you'll need a rollback action in Case the installation fails or the user cancels it. You'll also probably need an uninstallation action that reverses the changes during uninstallation; And also an uninstallation rollback action, in case the uninstallation fails or the user cancels it, and you need To undo whatever just undid. Luckily, the same condition logic applies:if your deferred uninstallation action uses condition remove= "All", yo ur uninstall-rollback action can use the same condition.

and Finally ...

If your deferred action saves any temporary data-similar to how the InstallFiles action temporarily caches files it might Need to restore-your rollback action can clean up that data when it reverses the effects of the original action. But what if the rollback action never runs?

Windows Installer defines yet another type of action, called a commit action, which runs only if the installation Successfully runs to completion. If a rollback action runs, a commit action won ' t run; And if a commit action runs, it's too late for rollback. Defining an action as a commit action in InstallShield also involves the In-script execution setting, and follows the same Condition logic as other deferred and rollback actions.

To summarize, if you create a custom action this makes changes to a target system, you might wind up making several others To handle rollback, uninstallation, uninstallation rollback, and cleanup. If that's not a good argument for avoiding custom actions that duplicate Windows Installer functionality, I don ' t know WHA T is.

For more information and some hands-on experience-plus information on how to things get trickier with all these deferred, Rollback, and commit actions needing to the Read property Values-come visit us on our advanced Windows Installer (MSI) Using I Nstallshield Training Course.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.