Beginning with Windows Installer 2.0 installation developers can write installation packages that target 64-bit platforms. At first only IA64 was supported but support for AMD64 — now collectively referred to along with EM64T as x64 — was added in Windows Installer 3.0. Many questions are asked regarding how to author 64-bit packages and merge modules so I will attempt to enumerate and briefly explain the available resources here.
The point of authoring a package differently for 64-bit platforms is to deploy 64-bit binaries and write registry values for 64-bit access correctly. While you can install a 32-bit application on 64-bit Windows, files for 32-bit execution will be redirected to different folders and some registry values for 32-bit access will be redirected to a different parent registry key. Before you can control where files are installed on 64-bit platforms you must author your installer database as a 64-bit installation package. To do this you must set the Template summary property to either Intel64 or x64; Intel, Intel64, and x64 are all mutually exclusive. For these values to be effective the database schema must be set to at least 200.
To make sure that the file system and registry aren’t redirected when installing 64-bit executables, their support files, and registry values for 64-bit access, components that contain those files and registry values must be marked appropriately with the msidbComponentAttributes64bit (256) attribute in the Component table and must target the appropriate 64-bit directories. Components and actions can also be conditioned to install or run only on 64-bit platforms.
- Using 64-bit Windows Installer Packages
- System64Folder property
- ProgramFiles64Folder property
- CommonFiles64Folder property
- VersionNT64 property
- Intel64 property
- Msix64 property
- ICE80
If you’re authoring a 64-bit package with both 32- and 64-bit binaries, make sure that they resolve to different source and target directories when considering how they lay out on installation media and how files will be extracted during an administrative install otherwise 32- and 64-bit files will overlap each other and cause problems. If a 32-bit component is contained in both a 32-bit installation package and a 64-bit installation package it may have the same component ID but 32- and 64-bit components should have different component IDs, just as 32- and 64-bit products should have different product codes.
For 64-bit installation packages you’ll probably want to run 64-bit custom actions. 64-bit executables will run in either a 32- or 64-bit custom action server correctly but script custom actions must be marked as either running in a 32- or 64-bit script host by being marked appropriately with the msidbCustomActionType64BitScript (4096). Custom action scripts are not recommended, however.
If you want to author merge modules that contain 64-bit binaries and support files and want to merge them into a 64-bit installer package, you’ll also need to set the Template summary property to either Intel64 or x64. Only Intel64 merge modules can be merged into Intel64 installer packages, and only x64 merge modules can be merged into x64 installer packages. 32-bit merge modules can be merged into any installer package.
To help validate that an installation package is authored correctly to install 64-bit binaries and support files and registry values, be sure to run validation — especially ICE80.
There are also error codes and Windows Installer error messages you might want to handle that relate to installing 64-bit packages.
- 1633 — This installation package is not supported on this platform. Contact your application vendor.
- 2401 — 64-bit registry operation attempted on 32-bit operating system for key [2].
- 2943 — This version of Windows does not support deploying 64-bit packages. The script [2] is for a 64-bit package.
0 comments