We can call JScript, VBScript, DLLs, or an executable. Each of these may be installed during the deployment, be embedded within the package, or already present on the target platform.
Commonly a custom action makes changes to the target platform - such as writing to files, executing DB scripts, writing to registry or any other modification.
This is all well if the deployment finishes successfully. However what would happen were the user to click 'Cancel'? Or if some error happened during the deployment?
In these cases Windows Installer executes a rollback script starting at the action that failed/cancelled and going backwards.
The aim of rollback actions is to undo any modification to the target platform and revert the system back to the state it was at prior to the stopped installation.
Standard actions have their own rollback information written to the rollback script.
For custom actions that modify the target platform we need to provide a rollback actions.
So far we got 2 custom actions:
- Deferred custom actions that performs:
- Create backup prior to any modification
- Modify the target system
- Rollback custom action:
- Undo the modification (restore the backup)
- Remove the backup
After the installation has finished successfully we can rid of it. Here comes the commit custom actions - these actions are executed after the installation has finished successfully.
A commit custom action can delete the unused backup.
Now we ended up with the trio of custom actions for any modification to the target system.
To have it all executing orderly we need to sequence the rollback action first, the deferred custom action second, and the commit action last.
Per Dai Corry Comment - I agree that an uninstall custom action should be added to the triple, leading us to a "Custom actions come in quadruples" conclusion.