Category Archives: installation

Even developers are concerned about the environment…

Recently in the wix-users email list the following question was asked about hybrid installations:

Is it possible to create one MSI for both 32bit and 64 bit OS

Oh wait… You mean it’s not that type of hybrid? Well then, I think I can still help you out.

5 years ago, there were very few people would have even thought about supporting the x64 environment. However, the current processor lineups from the major vendors support both instruction sets natively. The usage of 64-bit operating systems is increasing. Making it more prevalent is the fact that the x64 versions of Windows contain a 32-bit subsystem to support 32-bit applications. This means in most cases, you don’t have to abandon your beloved 32-bit applications.

No one wants to maintain two installation codebases, it would be most convenient if both versions of the binaries could be supported in one installation package. Here is where the problem creeps in. Windows Installer only supports one processor architecture in the Summary Information stream. Of course, I wouldn’t even bother telling you this if there wasn’t a convenient work-around.

Since x64 versions of Windows support 32-bit applications, we can mark the Template Summary property as Intel;1033. While this does instruct Windows Installer to treat this package as a 32-bit package, Windows Installer allows for this package to contain components marked as 64-bit. Since the question comes from the wix-users list, we’ll focus on WiX for this entry, but the same principles can be applied to any Windows Installer project no matter what your tool of choice is.

Consider the following snippet from a WiX product file:
<Directory Id=”TARGETDIR” Name=”SOURCEDIR”>
<Directory Id=”ProgramFilesFolder”
ShortSourceName=”Progra~1″ SourceName=”Program Files”>
<Directory Id=”INSTALLDIR”
Id=”Common.txt” Guid=”{FC288E49-D459-4EE8-AC1F-375497A6E09B}”>
<File Id=” Common.txt” Name=”Common.txt” KeyPath=”yes” DiskId=”1″ Source=”SourceDirFileCommon.txt”/>
Id=”_32bit.txt” Guid=”{E4D22ADB-9A91-4388-8F5E-391DB1CCB211}”>
<Condition>(VersionNT) AND (NOT VersionNT64)</Condition>
<File Id=”_32bit.txt” Name=”32bit.txt” KeyPath=”yes” DiskId=”1″ Source=”SourceDirFile_32bit.txt”/>
<Directory Id=”ProgramFiles64Folder”
ShortSourceName=”PROGRA~1″ SourceName=”Program Files”>
<Directory Id=”INSTALLDIR1″ Name=”Test”>
Id=”_64bit.txt” Guid=”{8EE8C9CE-2F2A-43B8-B6B6-AD8E01A4109F}” Win64=”yes”>
<File Id=”_64bit.txt” Name=”64bit.txt” KeyPath=”yes” DiskId=”1″ Source=”SourceDirFile_64bit.txt”/>
<Feature Id=”32bit” AllowAdvertise=”system”
Display=”expand” Level=”3″ Title=”32bit”>
<ComponentRef Id=”_32bit.txt”/>
<Condition Level=”0″>VersionNT64</Condition>
<Feature Id=”64bit” AllowAdvertise=”system”
Display=”expand” Level=”3″ Title=”64bit”>
<ComponentRef Id=”_64bit.txt”/>
<Condition Level=”0″>VersionNT
AND NOT VersionNT64</Condition>
<Feature Id=”Common” AllowAdvertise=”system”
Display=”expand” Level=”3″ Title=”Common”>
<ComponentRef Id=”Common.txt”/>

The application is divided in to three features, 32-bit, 64-bit, and a common feature. The common feature contains the bits that will be common to both architectures and of course the other features contain the architecture specific bits. The components are then conditionalized to only install on their supported architectures. The good news is, this is not theory, I have tested this and it works.

There is of course a reason why you would not want to do this. Look at the size of the .NET Framework 3.5 redistributable. It’s HUGE! …and why do you think that is? Correct, it contains the binaries for all of the different processor architectures. Aaron Stebner has discussed this in a pretty recent blog post of his.

So no, it’s not that kind of hybrid, but it should at least help you in your development efforts.