13

I'm setting up 32- and 64-bit builds in WiX version 3.7. The WiX documentation is defective in explaining this adequately. In the documentation for Package/@Platform, it says "Use of this attribute is discouraged; instead, specify the -arch switch at the candle.exe command line", but there's no explanation of what this argument actually does (at least none that I can locate). The "documentation" for the compiler completely deserves the air-quotes around the word "documentation", as it's basically a stub (unlike the linker documentation, for example). For the historical record, here's the entirely of the compiler documentation:

The Windows Installer XML compiler is exposed by candle.exe. Candle is responsible for preprocessing the input .wxs files into valid well-formed XML documents against the WiX schema, wix.xsd. Then, each post-processed source file is compiled into a .wixobj file.

The compilation process is relatively straight forward. The WiX schema lends itself to a simple recursive descent parser. The compiler processes each element in turn creating new symbols, calculating the necessary references and generating the raw data for the .wixobj file.

The command line help offers a bit, but not enough.

-arch      set architecture defaults for package, components, etc.
           values: x86, x64, or ia64 (default: x86)

In a related question, Platform identification in WiX 3.0, there's one answer with a sliver of hint about what might be going on, but it's hardly sufficient, and I don't know if it's accurate.

  • Does the -arch argument have the same effect as setting the Package/@Platform attribute, or does it do more?
  • Does the argument affect anything available in the preprocessor? In particular, does it set the PLATFORM preprocessor variable? Does it set anything else?
  • What's an architecture "default"? Does an explicit Package/@Platform attribute override the command-line? Or vice-versa? Or (better yet) is there an error if there's an inconsistent platform declaration?

Some of these questions have answers that seem like they ought to be obvious, and indeed I've learned something just writing the question. But I'd like a definitive answer, preferably (hint) a link to an updated and accurate documentation page for the candle command line. I do expect to have solved this by the time anybody answers, however, but I'd just as soon save other people the time I'll have spent figuring this out.

Another related question, WIX: is the Platform attribute of the Package element truly deprecated?, talks about the Package/@Platform attribute, but doesn't address the command line argument.
About that PLATFORM preprocessor variable. It's now apparently BUILDARCH, though you'd be hard pressed to know it from the documentation. 
warning CNDL1034 : The built-in preprocessor variable '$(sys.PLATFORM)' is 
deprecated. Please correct your authoring to use the new '$(sys.BUILDARCH)' 
preprocessor variable instead.
Community
  • 1
  • 1
eh9
  • 7,340
  • 20
  • 43

3 Answers3

12

The following code snippets enable compile-time configuration between 32-bit and 64-bit versions without introducing a user variable representing the platform but rather using the one provided by the system. Both defined variables are generic to ordinary installs. The minimum version is higher for 64-bit systems. The base program files directory differs between 32- and 64-bit versions.

<?if $(sys.BUILDARCH)="x86"?>
    <?define Minimum_Version="100"?>
    <?define Program_Files="ProgramFilesFolder"?>
<?elseif $(sys.BUILDARCH)="x64"?>
    <?define Minimum_Version="200"?>
    <?define Program_Files="ProgramFiles64Folder"?>
<?else?>
    <?error Unsupported value of sys.BUILDARCH=$(sys.BUILDARCH)?>
<?endif?>

Use these definitions later in the WiX source. 
<Package [...]
    InstallerVersion="$(var.Minimum_Version)"
/>

<Directory Id="$(var.Program_Files)">
    [...]
</Directory>
eh9
  • 7,340
  • 20
  • 43
3

Partial answers:

  • The -arch argument does set the sys.BUILDARCH variable, as well as the sys.PLATFORM one.
  • The -arch argument silently overrides the attribute Package/@Platform. At least it seems to, if looking at sys.BUILDARCH is sufficient.
    • Thus the command line help is wrong. It's an override, not a default.
eh9
  • 7,340
  • 20
  • 43
  • How do you set the `-arch` switch to x64 if you are building the WiX installer in Visual Studio? – Jammer Apr 08 '14 at 10:03
  • 1
    @Jammer The `-arch` switch is set on the command line of `candle` after it's compiled; it's not involved in building that compiler. If you are asking if there's a way to make `-arch x64` the default for such a binary, I don't know the answer offhand. – eh9 Apr 08 '14 at 11:39
  • Ahh, I did work this out. If you set the `PlatformInstaller` property to x64 in your `.wixproj` file the command line to candle will include the -arch x64 switch. – Jammer Apr 08 '14 at 11:58
  • How does `candle -arch` affect the product code and upgrade code if you use it to build the same product definition two different ways? – lesscode Jan 23 '15 at 19:04
  • @Wayne I don't think it affects either of those two by default. If the two ways you're building it are different enough, you should likely use different product and upgrade codes for the different builds. – eh9 Jan 28 '15 at 20:11
  • @eh9 thanks, that's what I figured. In my case the product definitions are identical (same files - I install both x86 and x64), but I still need two MSI files because there are registry entries that need to be written either to the native registry or the WOW64 registry. I was hoping that the same .wxs file could just be "candled" with two different -arch options, but in reality I still need to include a conditional for the product and upgrade codes, because you're not supposed to produce two MSI's with different architectures but the same product/upgrade codes. Right? – lesscode Jan 28 '15 at 20:48
1

In addition to defining the MSI's architecture (Package/@Platform) it sets a default component table value for the msidbComponentAttributes64bit attribute in the MSI (Win64 in WiX).

IE. if sys.BUILDARCH = x86 then it is not set, if x64 then it is set (+256). This is not mentioned in the WIX.chm which just re-iterates the MSI.chm about the above attribute

Set this attribute to 'yes' to mark this as a 64-bit component. This attribute facilitates the installation of packages that include both 32-bit and 64-bit components. If this bit is not set, the component is registered as a 32-bit component.** If this is a 64-bit component replacing a 32-bit component, set this bit and assign a new GUID in the Guid attribute.

(So does not tell you) : When using BUILDARCH you only need to author Win64 WiX attribute when you want to override the defaults, helpful when building different arch MSIs from the same WiX code. Previous to this I was using an environment variable for a Win64 attribute on every component.

Matthew O'Connell
  • 26
  • 4