InstallAnywhere 2013
This section describes possible upgrade issues that may occur when you upgrade projects that were created with earlier versions of InstallAnywhere. It also alerts you to possible changes in behavior that you may noticed between InstallAnywhere 2013 projects and projects that are upgraded from an earlier version to InstallAnywhere 2013.
Upgrading from InstallAnywhere 2012 or Earlier
New Build Target for Pure 64-Bit Windows-Based Systems
InstallAnywhere 2013 Premier Edition has support for building installers that target pure 64-bit Windows-based systems on which 32-bit Windows-on-Windows (WOW64) support is disabled.
If you create a new project in InstallAnywhere 2013, it automatically includes a build target for pure 64-bit Windows-based systems by default. If you upgrade an InstallAnywhere 2012 or earlier project to InstallAnywhere 2013 Premier Edition, InstallAnywhere automatically adds this build target to your project.
Upgrading from InstallAnywhere 2010 or Earlier
Default Uninstall Behavior for Imported Merge Modules
If you import a merge module into an InstallAnywhere 2013 project, the Uninstall Merge Module when parent is uninstalled check box is selected by default. This check box lets you specify whether you want the merge module to be uninstalled from target systems when the parent project is uninstalled.
If you have an InstallAnywhere 2010 or earlier project that includes one or more imported merge modules, and you upgrade the project to InstallAnywhere 2013, the Uninstall Merge Module when parent is uninstalled check box is cleared by default for those merge modules.
If you want to change the behavior in either case, you can change the state of the check box:
• | To change the behavior for an individual merge module: On the Sequence tab, click Install. In the Visual Tree, select the merge module whose behavior you want to change. In the Install Merge Module customizer, on the Properties subtab, select or clear the Uninstall Merge Module when parent is uninstalled check box. |
• | To change the behavior for a dynamic merge module: On the Organization tab, click Modules. In the Imported Merge Module List, select the dynamic merge module whose behavior you want to change. In the Dynamic Merge Module customizer, on the Install tab, select or clear the Uninstall Merge Module when parent is uninstalled check box. |
VM Pack Creation
VM packs that are created using the Create VM Pack utility, which was introduced in InstallAnywhere 2011, can be used only with installers that are created in InstallAnywhere 2011 or later, not with installers that were created in earlier versions of InstallAnywhere (such as InstallAnywhere 2009 or InstallAnywhere 2010). If you want to use VM packs with any older installers (those that were created in InstallAnywhere 2010 or earlier), you must follow the manual process, as described in Creating a JRE VM Pack Manually.
Project Automation APIs and Configuring Behavior for Maintenance Mode and Instance Management
If you are upgrading an InstallAnywhere 2010 (without SP1) project to InstallAnywhere 2013 and you want to use the project automation APIs to modify maintenance mode and instance management in your project, it is recommended that you first open and save your project in the InstallAnywhere 2013 Advanced Designer.
Configuring Build Target Information through the BuildProperties.xml File
If you upgrade an InstallAnywhere 2010 or earlier project to InstallAnywhere 2013 and you were using a BuildProperties.xml file to configure build targets, note that some of the XML code has been changed. In InstallAnywhere 2011 and later, the buildWithVM, BuildWithNoVM, outputDir, and bundledVM settings are attributes of the <target> element. In InstallAnywhere 2010 and earlier, these settings were subelements of the <target> element. Therefore, if you upgrade an InstallAnywhere 2010 or earlier project to InstallAnywhere 2013, ensure that you update your BuildProperties.xml file accordingly.
Configuring Build Target Information through Ant Tasks
If you upgrade an InstallAnywhere 2010 or earlier project to InstallAnywhere 2013 and you were using an Ant task to configure build targets, note that some of the XML code has been changed. In InstallAnywhere 2011 and later, the buildWithVM, BuildWithNoVM, outputDir, and bundledVM settings are attributes of the <target> element. In InstallAnywhere 2010 and earlier, these settings were subelements of the <target> element. Therefore, if you upgrade an InstallAnywhere 2010 or earlier project to InstallAnywhere 2013, ensure that you update your Ant task accordingly.
Upgrading from InstallAnywhere 2009 or Earlier
Change to the Default Name of the Uninstaller Executable File
If you create a project in InstallAnywhere 2013, the default name for the uninstall launcher is Change ProductName Installation.exe.
If you created a project in InstallAnywhere 2009 or earlier, the default name for the uninstall launcher was Uninstall ProductName.exe; if you upgrade the project to InstallAnywhere 2013, InstallAnywhere does not change the name of the uninstaller launcher automatically. You may want to manually change the name. To do so: On the Sequence page, click Install. Then select the uninstall launcher and edit the value in the Name setting on the Properties tab.
Changes for Organizing Build Settings
InstallAnywhere has support for creating and maintaining different build configurations. Each build configuration defines how InstallAnywhere builds an installer for a particular set of platforms, build distributions, JVMs, locales, and other settings. You can store as many build configurations with a project as necessary. When you create a new project in InstallAnywhere 2013, it contains a default build configuration called Default Configuration.
InstallAnywhere 2009 and earlier did not have support for build configurations. If you open an InstallAnywhere 2009 or earlier project in InstallAnywhere 2013, InstallAnywhere displays the Build Settings Conversion Notice message box, which asks you if you want InstallAnywhere to convert the existing build settings automatically to the build configuration model. If you reply that you do want to convert it, InstallAnywhere upgrades all of the project’s existing build settings into a new build configuration called Migrated Configuration. If you want to modify the settings for this build configuration, you can do so. To learn more, see:
• | Defining Build Targets |
• | Specifying Build Distribution Options |
• | Using Tags to Customize Build Configurations |
• | Specifying Locale Settings |
Changes for Locales
In InstallAnywhere 2009 and earlier, the locales directory in the build output folder was named <project_name>locales. If you are upgrade an InstallAnywhere 2009 or earlier project to InstallAnywhere 2013, you must rename this directory with the following naming convention:
<project_name>locales_<build_configuration_name>
Once you have renamed the folder, rebuild the project in InstallAnywhere 2013.
Changes Related to Rollback Behavior
InstallAnywhere has built-in support for rollback behavior: On the Rollback tab of action customizers in the Install view of the Sequence page, you can specify rollback behavior on a file-by-file basis. You can fine-tune how the installer treats individual project elements during a rollback and can specify which project elements would trigger a rollback if the installation of that element fails.
InstallAnywhere 2009 and earlier did not have built-in support for rollback behavior; these versions included support for custom code that triggered a rollback handler; if an end user cancelled the installation, the rollback handler was called.
If you upgrade a project from InstallAnywhere 2009 or earlier with the rollback handler code to InstallAnywhere 2013, the rollback handler code is launched only if the Enable Rollback check box is cleared; this check box is in the Advanced view on the Project tab. To learn how to use the new built-in rollback behavior, see Configuring Installation Rollback Behavior.
Upgrading from InstallShield MultiPlatform
Changes for Organizing Build Settings
InstallAnywhere has support for creating and maintaining different build configurations. Each build configuration defines how InstallAnywhere builds an installer for a particular set of platforms, build distributions, JVMs, locales, and other settings. You can store as many build configurations with a project as necessary. When you create a new project in InstallAnywhere 2013, it contains a default build configuration called Default Configuration.
If you use a project manifest to upgrade an InstallShield MultiPlatform project to InstallAnywhere 2013, InstallAnywhere creates a new build configuration called Migrated Configuration for the upgraded project. If you want to modify the settings for this build configuration, you can do so. To learn more, see:
• | Defining Build Targets |
• | Specifying Build Distribution Options |
• | Using Tags to Customize Build Configurations |
• | Specifying Locale Settings |
InstallAnywhere 2013 Help LibraryOctober 2013 |
Copyright Information | Contact Us |