Summary
When the end-user cancels the install phase of any installer generated by InstallAnywhere, the execution is interrupted right after the action currently being installed completes its job and all files and other items installed up to this point are left on the target system.Synopsis
This article gives information about cancelling installer and rollback.Discussion
In the installers built with InstallAnywhere versions prior to InstallAnywhere 2010, if you cancel during an install while files are being copied, the install files in the temp directory will get removed, but the files being copied from the installer at that time will not. However, InstallAnywhere 7.1 and above allows you to run custom code that will be triggered by a cancellation.
Additional Information
InstallAnywhere 2010 has introduced a built in functionality for Rollback. When a project using a custom action which implemented the RollbackHandler interface is migrated to InstallAnywhere 2010 or later, and if the Enable Rollback option is enabled, the Custom Action which implements the RollbackHandler will never be called. If this action needs to be called during an incomplete installation, the Enable Rollback option must not be selected. For more detail information on this new feature, follow the KB article: Explanation of the Rollback FunctionalityInstallAnywhere Custom Code Rollback ? User Guide
When the end-user cancels the install phase of any installer generated by InstallAnywhere, the execution is interrupted right after the action currently being installed completes its job and all files and other items installed up to this point are left on the target system.
InstallAnywhere now provides support for custom code actions to roll back any changes made to the target system after the user has cancelled the install in GUI mode.
During the execution of a custom code action, InstallAnywhere provides some services so that the action can access different resources made available by the installer or interact with different aspects of the install, such as the user interface.
InstallAnywhere now provides a rollback registration service that can be requested by a custom code action at the beginning of its execution. Through this service, the action can register a rollback handler, which will be executed by InstallAnywhere if the install is cancelled.
The rollback handler will need to have access to the action at rollback time in order to guarantee it has enough information to be able to roll back the install of that specific action. In fact, nothing prevents the action itself from being the rollback handler.
The execution of all rollback handlers will proceed in the reverse order in which they have been registered. That guarantees that each action will find the system in the expected state for the rollback to be performed cleanly in the case one action uses resources installed by another.
In most cases, every rollback handler must attempt to roll back the system to a previous state only if it has enough information to do so, and it must only try to roll back those items that have been installed by the associated custom code action.
However, there might be cases in which one custom code action is implemented with the only purpose of providing a handler that will roll back all the custom code actions that will follow during the install. That would be the case when there is no source code available to change a custom code action in order to make it support its own rollback.
public class RollbackAction extends CustomCodeAction
{
private static final String FILE_NAME = "installed-file.txt";
public void install (InstallerProxy proxy) throws InstallException
{
installFile(proxy);
}
private void installFile(InstallerProxy proxy) throws FatalInstallException
{
String installDir = proxy.substitute("$USER_INSTALL_DIR$");
try
{
FileOutputStream stream - new FileOutputStream(new File(installDir, FILE_NAME));
try
{
stream.write("contents".getBytes("UTF-8"));
}
finally
{
stream.close();
}
}
catch (IOException exception)
{
throw new FatalInstallException{exception.getMessage());
}
}
As you can see, this action will create a file at the install directory. If the install is cancelled at any point after this file has been installed, the action?s rollback handler should be able to remove the file.
In order to do that, you add the following code to the action?s install method prior to installing the file:
public class RollbackAction extends CustomCodeAction
{
private static final String FILE_NAME = "installed-file.txt";
public void install (InstallerProxy proxy) throws InstallException
{
registerRollbackHandler(proxy);
installFile(proxy);
}
private void installFile(InstallerProxy proxy) throws FatalInstallException
{
RollbackRegister register = (RollbackRegister)proxy.getService(RollbackRegister.class);
register.addHandler(
new RollbackHandler()
{
public void rollback(InstallerProxy proxy)
{
String installDir = proxy.substitute("$USER_INSTALL_DIR$");
File installedFile = new File(installDir, FILE_NAME);
if (installedFile.exists()) installedFile.delete();
}
});
}
Notice that the action asks the proxy for the RollbackRegister service, which then allows the action to provide a RollbackHandler. Once the installer is ready to roll back the install, it will call the rollBack method implemented by the handler.
In this example, the rollBack method is implemented in line. It uses the installer?s proxy to know where the file has been installed to and then deletes the file if found. The rollBack method knows the name of the file to be deleted because it is executed in the context of the action. If the handler had been implemented in a separate class, it is responsibility of the action that instantiates the handler to pass a reference to itself or provide all the information the handler will need to perform the rollback.
Alternatively, the custom code action can implement the RollbackHandlerinterface directly, in which case it will automatically be registered as its own handler right before its install method is executed, and thus all the information required for the rollback should be available at rollback time.
See the alternative implementation below:
public class AutomaticRollbackAction extends CustomCodeAction implements RollbackHandler
{
private static final String FILE_NAME = "installed-file.txt";
public void install(InstallerProxy proxy) throws InstallException
{
installFile(proxy);
}
public void rollback(InstallerProxy proxy)
{
String installDir = proxy.substitute("$USER_INSTALL_DIR$");
File installedFile = new File(installDir, FILE_NAME);
if (installedFile.exists()) installedFile.delete();
}
As you were able to see, InstallAnywhere provides an easy way to implement rollback for your custom code actions through the implementation of the RollbackHandler interface or by registering your own handler with the RollbackRegister service.
NOTE: These are the only custom code classes currently available that can be executed by InstallAnywhere if an install is cancelled. Any coding needs to be implement within the rollback handler in order for it to perform when a customer hits the Cancel button.
Was this helpful?
Related Articles
Managing Oracle Universal Installer (OUI) evidence gathered by the FlexNet inventory agent 111Number of Views Explanation of the Rollback Functionality 8Number of Views What data does the FlexNet inventory agent gather as file and installer evidence? 99Number of Views InstallScript Debugger Does Not Debug Deferred, Commit, or Rollback InstallScript Custom Actions 3Number of Views Introduction to Windows Installer Upgrade Types 29Number of Views
Revenera Assistant - Beta
Online
Hi, I am Reva - Ask me anything.
Updates
No new updates
Chat
Home
Updates
/**/
Thanks for the feedback!
Your feedback has been saved.Rate this response:
1
2
3
4
5
Add Additional feedback ( Optional )
0/240
English
English
Language changed successfully
Something went wrong
Email sent successfully
Something went wrong
Case create successfully
Are you sure you want to cancel
the case creation?
Please select a product to submit the case.
Please select a product version to submit the case.
0/255
Upload Attachment
File Upload
Maximum file
size allowed is 3 MB.
File type
not supported.
Supported file types:
Documents (.txt, .doc, .docx, .pdf), Images (.jpg, .png), Comma Separated Files
(.csv) Speadsheets (.xlsx, .xls)
Are you sure you want to cancel the case creation?
Case closed successfully
File Upload
Maximum file size allowed is 3 MB.
File type not supported.
Supported file types:
Documents (.txt, .doc, .docx, .pdf), Images (.jpg, .png), Comma Separated Files
(.csv) Speadsheets (.xlsx, .xls)
Are you sure you want to close this case
| Products | Region | Phone Numbers |
|---|---|---|
| FlexNet Operations FlexNet Embedded FlexNet Publisher FlexNet Connect FlexNet Code Insight InstallAnywhere InstallShield |
North America * |
+1 630-332-2513 (toll) +1 877-279-2853 (toll-free in North America) |
| Europe * |
+44 1925 944367 (toll) +44 800 047 8642 (toll-free in Europe) |
|
| Japan * | +81 3-4540-5335 (select option 2) | |
| Australia * |
+61 3 9895 2177 +61 1800 560 603 (toll-free in Australia) |
|
|
Usage Intelligence (formerly
Revulytics) Compliance Intelligence |
Please use the Case Portal to submit your support ticket or reach out to your Revenera contact. | |
File Upload
Maximum file
size allowed is 3 MB.
File type
not supported.
Supported file types:
Documents (.txt, .doc, .docx, .pdf), Images (.jpg, .png), Comma Separated Files
(.csv) Speadsheets (.xlsx, .xls)
© 2026 Flexera Software. All Rights Reserved.
Case id: 00001065
Activity: Status change: 2 hours ago