How to conditionally install components based on processor architecture type (32-bit or 64-bit)?

Now I'm giving the promised answer on the processor instruction-set architecture and the implication of different architectures on installation.

First of all, it's good to know the available architectures and their names, as their naming is confusing. To best of my knowledge, Windows installer is presently applicable to the systems using the following 3 architectures: x86, x86-64 (AMD64) and Itanium (IE64). They are all incompatible, but both 64-bit processors run x86 32-bit processes, and this is supported on Windows via WoW64. Please see:
http://en.wikipedia.org/wiki/Instruction_set[^],
http://en.wikipedia.org/wiki/X86[^],
http://en.wikipedia.org/wiki/X86-64[^],
http://en.wikipedia.org/wiki/Itanium[^],
http://en.wikipedia.org/wiki/WoW64[^].

The most usual 64-bit architecture these days is x86-64, but many call it just 64-bit or x64, but this is not an original 64-bit architecture, which is actually IE64, these days usually known as Itanium. The cheaper and more usual x86-64 architecture was originally developed by AMD (hence "AMD64") as the extension of x86, and later embraced by Intel who preserved its original IE64 for more expensive higher level systems. This all often creates all kinds of confusions.

One of the ways to detect the architecture during runtime using the installation built with WiX is to check up the environment variable PROCESSOR_ARCHITECTURE, so the results will depend on how Windows name those architectures in the correspondent variable. The architectures are known under the following names: "x86", "AMD64" and "IE64".

The MSBuild and Visual Studio terminology is different. The names of the same architectures are "x86", "x64" and "Itanium". And, instead of the term "instruction-set architecture", the term "Platform" is used. We will need to use this information below.

You can identify the system operating during installation runtime using WiX <Condition> element, which can be a child of the element <Component>. Therefore, you discriminant the files to be installed at the level of components. (For other possible elements which can use the child element <Condition>, please see the link below.) It can look like that:

<DirectoryRef Id="CUSTOM.INSTALLATION.DIRECTORY">
   <Component Id="ApplicationFiles64" Guid="{4A91A21D-FC99-419C-8144-211DE78014C6}">
      <File Id="ApplicationFile1" Source="SourceFiles/Some-x86-file.dll" />
      <Condition> %PROCESSOR_ARCHITECTURE="x86" </Condition>
   </Component>
   <Component Id="ApplicationFiles64" Guid="{E59BB1E9-9B56-4355-BCDC-F03501D326A8}">
      <File Id="ApplicationFile1" Source="SourceFiles/Some-x86-64-file.dll" />
      <Condition> %PROCESSOR_ARCHITECTURE="AMD64" </Condition>
   </Component>
   <Component Id="ApplicationFiles64" Guid="{1AD7798A-BE64-4063-AD31-7F386371A150}">
      <File Id="ApplicationFile1" Source="SourceFiles/Some-IE64-file.dll" />
      <Condition> %PROCESSOR_ARCHITECTURE="IE64" </Condition>
   </Component>
</DirectoryRef>

Of course, a component can have any number of files and actions. By the way, don't forget that you should generate the whole unique GUID every time it is required by the syntax.

Please see:
http://wix.sourceforge.net/manual-wix2/wix_xsd_condition.htm[^],
http://wix.sourceforge.net/manual-wix2/wix_xsd_component.htm[^].

This is not the only approach you can use to approach multiplatform/cross-platform installation. There is a number of reasons when you may want to create different MSI of each platform or combine both approaches. The creation of per-platform MSI is well supported if you use MSBuild and/or Visual Studio. The standard way to support it is to use the standard properties $(Platform) and $(Configuration). In particular, you can have different output directories for all combinations of platforms and combination if you put in a corresponding property definition the path like ..\..\$(Configuration)-$(Platform) (the number of ".." will depends on depth of each project relative to your common output directories. You can also put your WiX project in the same solution as your project. Using this naming/path scheme (or any other scheme based on this idea), you can put each kind of resulting MSI file to the same directory as the product itself, so each MSI would pick up output files of correspondent instruction-set architectures.

But still, sometimes you would need to conditionally include some files from some other sources, or just the files with different names, depending on the architecture. This is very typical when you have to deploy some 3rd-party executable files, such as DLLs. How to do it?

The value of the MSBuild property $(Configuration) is known to the WiX preprocessor. Here is how you use it:

<?if $(var.Platform)="x86" ?>
   <!-- declare something for x86 -->
<?endif?>

<?if $(var.Platform)="x64" ?>
   <!-- declare something for x86-64 -->
<?endif?>

<?if $(var.Platform)="Itanium" ?>
   <!-- declare something for IE64 (Itanium) -->
<?endif?>

You can also use <?else?>.

On the use of WiX preprocessor, please see: http://wix.sourceforge.net/manual-wix2/preprocessor.htm[^].

—SA

This is literally the stupidest set of answers I've EVER heard.
Q: I'm using InstallShield 2009...….
A: Well, let's gloss over that and I'll give you answers for WiX instead.

It's as stupid as, someone asking for help with FruityLoops on PC and them answering with, "Ah, but you can do it like this with Logic Pro on a Mac".

Mental.


However, just to help you out with your InstallShield 2009 problem, in the component itself you can specify an architecture type. Remember, this is a component, not a feature attribute.