Using Wix to create 32bit and 64bit installers from one .wxs file

Question

I would like to keep my top level .wxs DRY while building 32 and 64 bit installers. I am using the -arch argument to candle.exe to control what default installer architectur

Answer 1

Rather than conditionally including the opening Directory elements (which invalidates the XML), conditionally set preprocessor variables which are used as directory names, as @Daniel Pratt's comment refers to. Similarly, having a "yes/no" variable conditioned on platform makes it easy to set up 64 bit components, registry searches, etc.

Defining the variables

(From this answer)

$(var.Platform) is built-in, but its value is used to define custom variables $(var.ProductName), $(var.Win64) and $(var.PlatformProgramFilesFolder).

Using the variables

You can either use preprocessor directives to test variables' values (as is done with $(var.Platform) when defining the custom variables above) or have the preprocessor insert variables' values into XML attribute or element values. Couple of examples:

32/64-bit components

   ...

This will produce warnings in the Visual Studio WiX editor about $(var.Win64) not being one of the allowable attribute values (yes/no) but these can be safely ignored, because the preprocessor will have substituted an appropriate value by the time the compiler gets hold of it.

32/64 bit Program Files directory

  ...

---

Update to handle separate 32/64 bit product codes

In response to rharrison33's comment asking how to handle the requirement for different product codes (or pretty much anything) in the 32 and 64 bit installers (assuming you can't/don't want to auto-generate them):

• Pass separate product codes to candle as preprocessor variables, on the command line or using a response file:

candle  -d ProductCode32= -d ProductCode64=

• Add a product code as one of your architecture-dependent preprocessor variables, and set it to the appropriate input variable:
  • In the 32-bit branch:
  • In the 64-bit branch:
• Refer to $(var.ProductCode) in Product/@Id.

---

Made this CW because Daniel's link answers the question and has a lot more great info besides.