Definetely one my pet peeves about Windows Installer is how it deals with instruction set architectures (ISAs). Looking at Windows NT history, supported ISAs have come (amd64, IA-64) and gone (Alpha, PowerPC, MIPS) – yet most of the time, there was more than one ISA being officially supported. Having to ship binaries for multiple ISAs therefore always has been on the agenda for many ISVs.
Needless to say, supporting multiple ISAs requires special consideration when developing setup packages and providing separate packages – one for each ISA – has become common practice to approach this.
Continue »
Whenever Windows Installer’s built-in actions do not suffice to perform a specific task, a Custom Action needs to be written. Needless to say, Custom Actions, can be a bit tricky – not only can they be laborious to write and cumbersome to debug, they also run the risk of interfering with Windows Installer’s declarative, transactional way of performing installs.
It is not really surprising that Windows Installer therefore more or less discourages the use of Custom Actions unless it is absolutely necessary.
Continue »
Almost two years ago, I wrote about how to create multi-language MSI packages. Although using transforms to internationalize an MSI package is a viable solution, one drawback of this approach is that it may require a bootstrap loader.
While it is easy to say that a bootstrap loader is required and many high-profile setups do indeed use bootstrap loaders, bootstrap loaders do have their issues. They not only add complexity to the setup package, there actually are several reasons why a bootstrap loader-free setup may be preferrable.
Continue »
When authoring MSI packages, you frequently need the installation to be logged. Instead of repeatedly opening a console to type in msiexec /l* install.log /i foobar.msi, these shell context menu items may speed this process up a little. They do the same as ‘Install’ and ‘Uninstall’ but log everything (/l) to PackageName.msi-install.log or PackageName.msi-uninstall.log, respectively. Here are the registry entries:
Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Msi.Package\shell\LoggedInstall] @="&Logged Install" [HKEY_CLASSES_ROOT\Msi.Packageshell\LoggedInstall\command] @="msiexec.exe /l "%1-install.
Continue »
When testing a custom action, it is usally practical to have the CA write some information to the installer log, so that you can verify that the CA has been called properly. But what if the installer log does not show up your information but instead the installation aborts and the log only states that the custom action returned 3 (ERROR_INSTALL_FAILURE)?
There may be various reasons for this to happen, but the most common reason is probably that your DLL was unable to load because of unsatisfied dependencies.
Continue »
When Windows Installer performs a major upgrade, the position of the RemoveExistingProducts action determines when the uninstall of the old product is performed. Despite efficiency, two factors dominate the decision
What should happen if either the install or the uninstall fails? Should the new product ‘see’ registry entries/files/etc from the existing product or should the new product install ‘start from scratch’? The following table summarizes the four possible approaches.
Continue »
By default, Windows Installer packages are single-language only – no direct support for multi-language packages is currently provided. Creating a multi-lanuage installation package is thus a little more compex – the following provides a summary of the steps required:
Create an english package Compile: candle -dLANG=1033 foo.wxs Link: light -out foo.msi -loc strings-en.wxl foo.wixobj Create the german (or whatever language) package Compile: candle -dLANG=1031 foo.wxs Link: light -out foo-de.msi -loc strings-de.
Continue »
Mixing 32 and 64-bit components in a single MSI