Targeting 64-Bit Operating Systems with Basic MSI and InstallScript MSI Installations
InstallShield 2020
Project:This information applies to the following project types:
| • | Basic MSI |
| • | InstallScript MSI |
Note that if you create an InstallScript MSI project and change the Template Summary property from Intel to x64, InstallShield creates a 64-bit MSI installation combined with a 32-bit InstallScript MSI installation at build time.
Also note that InstallScript MSI projects do not have support for architecture validation.
If you are writing applications for 64-bit Windows-based systems, you will need a way to install your 64-bit files and other data. Although 32-bit Windows Installer–based installations can run on most 64-bit machines, they cannot install to 64-bit locations. The Windows Installer service provides support for 64-bit installations. These installations can be designed and built on 32-bit machines, but they can run only on 64-bit machines. Through the use of release flags, you can build two installations (one 32 bit and one 64 bit) from a single project.
Configuring the Template Summary Property
The Template Summary property determines whether an .msi package is a 32-bit package or a 64-bit package.
If your installation targets 64-bit systems, configure the Template Summary property with the appropriate 64-bit value (x64 or Intel64). This allows end users to install your product in 64-bit locations on 64-bit systems; it also prevents end users from installing your product on 32-bit systems.
You can use the Template Summary setting in the General Information view to configure the Template Summary property. You can also set the Template Summary setting for a product configuration in the Releases view. Any value entered in the Releases view overrides the value set in the General Information view.
To learn more, see Using the Template Summary Property.
Creating 64-Bit Components
To specify that a component is 64 bit, select Yes for the component’s 64-Bit Component setting. If you build a release that has at least one 64-bit component and the Template Summary property is set to a 64-bit value, the result is a 64-bit package.
For more information about the 64-Bit Component setting, as well as additional component settings, see Component Settings.
Extracting COM Data from 64-Bit COM Servers
If you are using InstallShield on a 64-bit operating system, InstallShield can extract COM data from a 64-bit COM server. In order to install the data to the correct locations, the component must be marked as 64 bit.
Note that if you use InstallShield on a 32-bit system, 64-bit COM extraction is not available.
To learn about extracting COM data, see Extracting COM Information from a COM Server.
Self-Registering 64-Bit COM Servers
InstallShield supports 64-bit self-registration of COM servers. If you mark a component as 64 bit and then add a file to that component, you can select the file’s Self Register check box to enable 64-bit self-registration of that file during installation. The Self Register check box is on the file’s Properties dialog box.
InstallShield also supports 64-bit self-registration of dynamically linked COM servers. To enable this, select the Self-Register all files check box on the Dynamic File Link Settings dialog box when you add the files dynamically to a 64-bit component. For more information, see Adding Dynamic File Links to Components.
Enabling or Disabling Registry Reflection
InstallShield includes support for the Windows Installer 4.0 and later attribute msidbComponentAttributesDisableRegistryReflection in the Component table. To use this attribute, set the Disable Registry Reflection setting for a selected component in the Components view to Yes. Registry reflection keeps the 32-bit registry view and the 64-bit registry view in sync on a target machine. Only 64-bit systems with Windows Installer 4.0 and later support this setting. Other systems ignore it. For more specific information, see Enabling and Disabling Registry Reflection.
Adding Other 64-Bit Elements
InstallShield includes support for additional 64-bit elements. For example, InstallShield includes 64-bit .NET Framework redistributables that you can add to your project. Custom actions can include 64-bit JScript or VBScript code, and 64-bit folder properties give you access to essential operating system folders such as the 64-bit Program Files folder. In addition, you can use the Setup Prerequisite Editor to configure setup prerequisites that have conditions that check for 64-bit requirements on the target system.
Note:64-bit support requires Windows Installer version 2.0 or later.
Specifying the Appropriate Architecture Validation
Basic MSI projects include a product configuration setting that lets you specify whether you want to use architecture validation at build time. Architecture validation enables you to detect potentially problematic cases in which your installation may try to install product files or use run-time binaries that may not match the architecture of a target system.
For example, if end users may run your installation on 64-bit Windows Server Core systems that do not have 32-bit Windows-on-Windows (WOW64) support, architecture validation can help you identify any 32-bit product files or 32-bit custom action files in your installation; 32-bit binaries cannot be loaded on 64-bit target systems without WOW64 support.
Architecture validation also enables you to generate pure 32-bit .msi packages that contain only 32-bit versions of the built-in InstallShield custom action DLLs, or pure 64-bit .msi packages that contain only 64-bit versions of the built-in InstallShield custom action DLLs.
To specify what type of architecture validation you want to use at build time and identify whether you want to build a pure 32-bit or 64-bit package, use the Architecture Validation setting for a product configuration in the Releases view.
For more details, see Selecting the Appropriate Type of Architecture Validation for Builds.
Tips for Building Two Installations—One 32 Bit and One 64 Bit—from a Single Project
If you want to be able to build two installations (one 32 bit and one 64 bit) from a single project, consider using release flags. You can assign release flags to features, InstallShield prerequisites, and chained .msi packages, as necessary, to differentiate the 32-bit items from the 64-bit items. Then you can configure each release or product configuration in the Releases view to include or exclude certain items that have a particular release flag at build time. You can also conditionally launch certain custom actions based on release flags, so that 32-bit custom actions are launched during a 32-bit installation and 64-bit custom actions are launched during a 64-bit installation.
To learn more, see:
| • | Release Flags |
| • | Filtering Based on Release Flags |
| • | Conditionally Launching Custom Actions Based on Release Flags |
InstallShield lets you override the values of your project’s path variables for each release in your project. This functionality enables you to essentially replace certain files and folders in your project with others at build time, depending on the particular release that you are building.
For example, you might use this functionality to swap out the binaries for custom actions. If you have set up separate releases for 32-bit and 64-bit target systems, you can override the path variable that is used to refer to the DLL that is selected for a custom action. Then InstallShield could include a 32-bit DLL for your 32-bit release and a 64-bit DLL for you 64-bit release. Note that overriding path variables to swap out files that your installation is installing is not recommended. This is because you should use separate components for 32-bit and 64-bit versions of a file.
To override one or more path variables in your project, use the Path Variables Overrides setting, which is on the Build tab for a release in the Releases view. For more information, see Build Tab for a Release.
See Also
Adding .NET Framework Redistributables to Projects
Using 64-Bit Windows Installer Packages (Windows Installer Help Library)