Open topic with navigation

Upgrading InstallShield 11.5 or Earlier Basic MSI Projects that Have InstallScript Custom Actions

InstallShield 2015

The following sections explain details about upgrading Basic MSI projects that were created in InstallShield 11.5 or earlier to InstallShield 2015.

Global Variables, Global Pointers, and SUPPORTDIR

With InstallShield 12 and later, when a Basic MSI installation executes an InstallScript custom action, the compiled InstallScript is loaded before the action is called, and it is unloaded after the action completes. Thus, each InstallScript custom action executes in its own session with complete InstallScript engine loading and unloading. This behavior is different than with InstallShield 11.5 and earlier: the compiled InstallScript was loaded once before the first InstallScript custom action that was used by the InstallScript was executed, and it was unloaded at the end of the installation after all InstallScript custom actions were completed.

A major implication of this change in behavior is that global variables and pointers are no longer maintained between individual InstallScript custom action calls:

Another implication of this change is that each custom action initializes and uses its own individual SUPPORTDIR. Therefore, you cannot share information across individual calls using files in SUPPORTDIR, since each custom action invocation will have its own unique SUPPORTDIR. You can share information using FOLDER_TEMP or some other file location.

Note that FOLDER_TEMP may not be the same path for all of your InstallScript custom actions. If you have some InstallScript custom actions that run in system context and some that do not, they will have different temp paths if the package is running in an elevated state. The InstallScript custom actions run in the context of a different user, so storing files in the temp directory and retrieving it later may not work in certain scenarios.

Windows Installer Properties and Deferred, Commit, and Rollback InstallScript Custom Actions

Deferred, commit, and rollback InstallScript custom actions in Basic MSI installations have access to only some of the built-in Windows Installer properties: CustomActionData, ProductCode, and UserSID. If you want an InstallScript custom action to access any other properties (such as SUPPORTDIR) during deferred, commit, or rollback execution, you need to pass them as CustomActionData. You can do so by scheduling an immediate set-a-property type of custom action (or, for example, an immediate InstallScript custom action with the MsiSetProperty function) to set a property that matches the name of the custom action. The value of this property is then available in the CustomActionData property within the deferred custom action.

For example, if you want to access a property such as SUPPORTDIR, you could create an immediate custom action that is called MyCustomActionName and that sets the MyCustomActionName property to [SUPPORTDIR], and then substitute "SUPPORTDIR" with "CutomActionData" in the MsiGetProperty call:

MsiGetProperty(hMSI, "CustomActionData", szSupportDir, nLen)

For more details, see the following:

Note that failure to compensate for an unavailable Windows Installer property may cause unexpected results during installation. For example, since in a deferred action, MsiGetProperty(hMSI, "INSTALLDIR", szInstallDir, nLen) sets szInstallDir to the empty string, szInstallDir ^ szFile may refer to a file in the current directory instead of a file in [INSTALLDIR]. The current directory for a deferred custom action is often [SystemFolder].

Deferred, commit, and rollback InstallScript custom actions do not have access to the ProductLanguage property. If your installation includes multilanguage support and it also has a deferred, commit, or rollback InstallScript custom action that needs access to the language in which the end user is running the installation, the installation assumes that this language is the installation’s default language. This could be a problem if an end user runs the installation in a language other than the default language. However, deferred, commit, and rollback custom actions do not typically display any user interface, so this would usually not be a problem.

Predefined InstallScript Event Handler Functions

The predefined InstallScript event handler functions are no longer available in Basic MSI projects with InstallScript custom actions. In InstallShield 11.5 and earlier, the following InstallScript event handler functions were available for Basic MSI projects:

InstallShield no longer supports these event handler functions for Basic MSI projects that have InstallScript custom actions. They are not called once the project is rebuilt with InstallShield 12 and later. Note that these event handler functions still compile in InstallShield 12 and later; they are just not called.

If you use these event handler functions in your project, you need to manually schedule custom actions that call these functions. To learn how, see Creating and Scheduling InstallScript Custom Actions that Call InstallScript Event Handlers for Basic MSI Projects.

InstallShield InstallScript Scripting Engine Merge Module

Beginning with InstallShield 12, the InstallShield scripting engine merge module is no longer available for inclusion in Basic MSI projects. In InstallShield 11.5 and earlier, you could use this merge module to distribute the InstallScript engine for installations that did not include Setup.exe. InstallShield 12 and later automatically includes the InstallScript engine as part of ISSetup.dll in Basic MSI installations that have InstallScript custom actions, regardless of whether Setup.exe is used. Therefore, you do not need this merge module in InstallShield 2015 projects.

If you use InstallShield 2015 to try to build a release for a project that has this merge module, you may encounter a build error such as the following one:

ISDEV : error -4075: File not found. An error occurred merging Module 'InstallShieldScriptingEngine.4F635B62_07BF_4779_B74E_D80C29D508E3:0' for Feature 'NewFeature1'.

To resolve this build error, remove this merge module from your project; you can do so by clearing its check box in the Redistributables view.

Changes to the InstallScript Engine Files

With InstallShield 12 and later, Basic MSI installations that include InstallScript custom actions no longer install InstallScript engine files to the following directory:

<COMMONFILES>\InstallShield\Driver\<Version>\Intel 32

For InstallShield 11.5 and earlier Basic MSI projects with InstallScript custom actions, several files were stored in the Binary table:

For InstallShield 12 and later, all of these files (except ISScriptBridge.dll, which is no longer used) are stored inside the ISSetup.dll file, and that is the only file that is stored in the Binary table.

The InstallScript engine file changes have not been known to cause any upgrade issues. These changes are reported for informational purposes.

See Also

Run-Time Behavior for Basic MSI Installations with InstallScript Custom Actions

Upgrading Projects from InstallShield 11.5 or Earlier