|Commit and Rollback Custom Actions|
All deferred custom actions are executes as part of a "transaction" (just like SQL database changes), if any part of this transaction fails then Rollback of any changes already made occurs. If the transaction completes successfully then the changes are committed.
Sometimes commit/rollback support is almost impossible to add and other times it is overkill, for example in a corporate rollout of a well tested application where failure won't damage the computer or effect future successful installation.
Note that because "immediate" custom actions are not part of a transaction they should not update the computer (they should be query only) as any effects can't be undone.
Rollback custom actions must be scheduled before the custom action that will perform the changes, the commit custom action should be after, all of these must must of course be scheduled between "InstallInitialize" and "InstallFinalize".
Most of the deferred custom actions demonstrated in this manual do not support commit and rollback because it would very much complicate the logic as it would require 3 seperate custom actions where one is currently used. It is also hard to do right, for this reason native Windows Installer mechanisms should always be used where available.