Rollback Actions are triggered when the setup encounters an abort situation and the internal “Rollback” script is invoked. Without going into details of the Rollback script – essentially what the setup does to modify the workstation, the rollback script will undo. For example, any files installed will be removed; any shortcuts or registry entries added will also be removed.
But what if you have Custom Actions that serve to modify the workstation – these actions are not written into the internal InstallShield engine’s rollback script. When the setup encounters an abort situation and the rollback script is invoked, these modifications are not removed. In a worst case scenario, they might prevent the setup from being executed again.
The bottom line is – if you have Custom Actions that serve to modify the workstation during the setup, you should create the special “Rollback” Custom Actions that clean up those modifications.
These are some important issues that must be addressed when you create a Rollback Custom Action:
- Set the Rollback Custom Action to be sequenced before any Deferred Custom Actions that modify the workstation
- must be Deferred and sequenced after “InstallIntialize” and before “InstallFinalize”
- Use In-Script Execution “Rollback Execution”
For testing, if you are using an InstallScript CA, you can issue a MessageBox to indicate it’s running when invoked
To test the Rollback Custom Action, you can create an InstallScript Custom Action, and set the following:
- Calls simple InstallScript function “ISI_TestRollback”
- Set as Deferred Execution
- Sequence between “InstallIntialize” and before “InstallFinalize” and after the Rollback Custom Action
- Within script just place “return -1” to trigger error routine
When the function ISI_TestRollback fails, the InstallScript rollback script is triggered and the Rollback Custom Action should be activated. Then the actions can be handled to clean up the modifications that would normally be left.
Hope this helps!