Should the Files element allow you to set Bitness?

[jwhitworth-vicon]

I would like to set the Bitness of harvested files to "always64" but it does not seem possible with the new WiX 5.x Files element.

[robmen]

Why? What is your scenario that you need to set the Bitness?

[jwhitworth-vicon]

I am working on a project with a custom internal build system (something similar to CMake but written in-house in Python). This system generates Visual Studio projects which are then used to build Windows applications. Due to a limitation of the build system, 32-bit and 64-bit projects cannot be mixed within the same solution.

One application contains a custom Python API package that includes some compiled C/C++ code. So this API can be used with multiple Python interpreters (e.g. 32-bit and 64-bit), the application contains 32-bit and 64-bit versions of the Python API package. The application installs to "C:\Program Files\Blah" with the Python package being added into "C:\Program Files\Blah\SDK\Win32" and "C:\Program Files\Blah\SDK\Win64".

To get this working with the custom build system, the 32-bit and 64-bit API packages are built in their own solutions as merge modules which are then included in the application's 64-bit solution installer. I am trying to work around the ICE errors which are generated from using the 32-bit merge module in the 64-bit installer, by setting the Bitness="always64" attributes on all files and components in the merge modules.

I appreciate that these problems stem from the limitations of the custom build system and will completely understand if you don't want to change anything in WiX.

[robmen]

I am trying to work around the ICE errors which are generated from using the 32-bit merge module in the 64-bit installer, by setting the Bitness="always64" attributes on all files and components in the merge modules.

This does not sound like the right thing to do. Bitness should (almost) always (I'd have to think hard for a counter-case) only be used to set Bitness='always32' to correctly mark 32-bit Components when building a 64-bit package.

[jwhitworth-vicon]

Ah, what's the intended use for Bitness='always64' then, sounds like there isn't one?

For my specific problem, what are the other options for avoiding ICE80 warnings generated by installing the 32-bit merge module into the 64-bit program files folder in the main application installer?

• Disable the warning - would work but I'd rather keep it enabled to catch other genuine mistakes.
• Set the 32-bit Merge Module project to 64-bit - I started trying this but think I haven't got the wixproj configuration correct yet.
• Anything else?

[jwhitworth-vicon]

I have managed to set <InstallerPlatform>x64</InstallerPlatform> property in the .wixproj of the 32-bit MergeModule, which has fixed the ICE warnings I was having. This is also a much simpler solution than what I was previously trying.

Thanks for your help.

[robmen]

Uhh, <InstallerPlatform>x64</InstallerPlatform> changes your 32-bit Merge Module into a 64-bit Merge Module. You got rid of the errors by getting rid of your 32-bit Components. 😆

Ah, what's the intended use for Bitness='always64' then, sounds like there isn't one?

I had to think for a bit. Multi-architecture .wixlibs are a use case for Bitness. There aren't many cases, and they are usually advanced scenarios.

what are the other options for avoiding ICE80 warnings generated by installing the 32-bit merge module into the 64-bit program files folder

Install it into the 32-bit ProgramFilesFolder.

[robmen]

Regardless of my scenario, shouldn't it be there for consistency if you can set it on and already?

No. It is possible to do what you want with other existing elements. The Files element is designed to make common cases easier (much easier). It is an anti-goal to dump every corner case into it, clouding the common case and making it complicated again.