Condition to test if installing on 64-bit platform

[frnds1]

Is there a way for an if/endif statement or statements block conditional to the platform bitness? The requirement is to install the 32-bit version of the app on all systems and only also install the 64-bit version of the app on 64-bit systems.

For example (the build system has files in the actual path that mirrors the desired target system):

new Dir(@"%ProgramFiles%\My Company\My Product",  
    new Dir(@"x86",
        new File(@"C:\Program Files\My Company\My Product\x86\myapp.exe",
            new FileShortcut("My Product (x86)", @"%ProgramMenu%") { IconFile = @"myapp.ico" }),
            new Files(@"C:\Program Files\My Company\My Product\x86\*.*", f => !f.Contains("myapp.exe"))),
            //  Equivalent of if $(var.Platform) = x64 
            new Dir(@"x64",
            new File(@"C:\Program Files\My Company\My Product\x64\myapp.exe",
            new FileShortcut("My Product (x64)", @"%ProgramMenu%") { IconFile = @"myapp.ico" }),
            new Files(@"C:\Program Files\My Company\My Product\x64\*.*", f => !f.Contains("myapp.exe")))
            // Equivalent of endif 
            );

[oleg-shilo]

Yes, it is possible but we need to clear a few confusions here first.

The pseudo-code you provided is a setup definition that is compiled at your build machine and never executed at runtime when you execute the msi on the target machine. It means that whatever condition you put in your code snippet (e.g. $(var.Platform) = x64) is not going to be evaluated at runtime but only during build time. If you want to have both versions (x64 and x86) of a file only deploy one of them depending on the target system CPU then you need to include both files and simply have the conditions attached to each of them and the condition is to be true or false based on the OS type this file targets.
Something along the lines:

new File(@"Files\Docs\Manual.x86.txt")
{
    Condition = new Condition("NOT VersionNT64")
},
new File(@"Files\Docs\Manual.x64.txt")
{
    Condition = new Condition("VersionNT64")
},
. . .
project.BeforeInstall += args =>
{
    if(Environment.Is64BitOperatingSystem) // evaluated on the target system
        args.Session["VersionNT64"] = "true";
};

I am not sure if WiX offers a ready-to-go property that holds CPU info and can be used as a condition for the file. Probably it does. But in my example above I used my own property VersionNT64.

Another confusion is the hardcoded program files path in a few places: new File(@"C:\Program Files\My Company\My Product\x64\myapp.exe",. If you are simply taking these files from your build machine ProgramFiles and building them into your msi, that's fine. Very unusual but technically possible. But I you accidentally assume where your files will go on the target system then it's not the case. The destination will always be C:\Program Files (x86), even on x64 target systems. But maybe you already know that.

[frnds1]

Thank you.

To clarify the scenario, 32-bit files and 32-bit exe shortcut should always install under Program Files (x86) on Win32 and under Program Files on Win64. If Win64 system, additionally, the 64-bit files and 64-bit exe shortcut should install under Program Files. That is why they are in separate sub folders. So I need to know how to incorporate setting platform dynamically.
 
You beat me to my next question and that was to determine how to set platform conditionally (? project.Platform = Platform.x64 ?). If installing on a 64-bit system, set so everything goes to Program Files.

Is File the only class to assign condition? Can it be applied to Files? Ideally, I would like to condition the whole Dir block.

I found the documentation on Wix about their VersionNT64 property: https://wixtoolset.org/docs/v3/howtos/redistributables_and_install_checks/block_install_on_os/ When I tried their condition example: Condition = new Condition("![CDATA[Installed OR (VersionNT >= 600)]]") the build resulted in: error LGHT0204: ICE03: Bad conditional string; Table: Component, Column: Condition

An extension to this is issue is the check for Window 10 or greater. On Wix, it reads as if there are different approaches for whether the project is bootstrap or MSI.

[oleg-shilo]

To clarify the scenario, 32-bit files and 32-bit exe shortcut should always install under Program Files (x86) on Win32 and under Program Files on Win64.

That is exactly the confusion that I was trying to avoid. It is not how MSI technology works. Every MSI targets a specific CPU type OS. It's not a limitation of WixSharp or even WiX. It is an architecture of MSI.

MSI dictates that you create two msi files one for x64 and another one for x86 and then both of them bootstrapped.
Tough some tricks are possible. IE have a single msy installing in ProgramFiles86 but the individual files deployed based on the target OS CPU type.

In your OP you used a single msi as an example so my suggestions were about that "trick" approach.

about their VersionNT64 property

Yes, this is the property I used in my suggestion. I wasn't sure WiX/MSI has it set by default so was setting it by myself. But I tested a sample code and MSI does set this prop. Meaning you do not have to use project.BeforeInstall += args =>...

set platform conditionally (? project.Platform = Platform.x64 ?).

Yes, if you set it to Platform.x64 everything goes to Program Files, otherwise to Program Files (x86)

Can it be applied to Files?

Yes, when you call Files you can pass a lambda that can set the condition for every file:

new Files(@"..\Release Folder\x64\*.*", x => true)
{
    OnProcess = file =>    
        file.Condition = new Condition("VersionNT64");
},

[frnds1]

Thank you. Sorry for the confusion. We've been migrating legacy installs (built with installer tools that bundle up all these differences). Yes, we are on the same page with 32-bit msi and 64-bit msi. I was hoping to finesse a single bootstrap install for both scenarios. What has been tricky is looking at the problem top-down (WixSharp syntax to generate XML) and bottom-up (Wix XML syntax needed for correct MSI generation).

I couldn't figure out the OnProcess syntax. Brilliant! That enumerates the condition attribute.

Do the WixSharp project settings affect the output? For example, Wix builds depend on the build settings, but WixSharp template projects are CPU any. Do we need to set the build properties to determine the bit-ness? I read a reference that Wix burn was 32-bit and I didn't know if that impacted WixSharp bootstrap.

[oleg-shilo]

Do the WixSharp project settings affect the output?

Not at all. The best way to look at it this way:

• A normal VS build process is based on the build script (csproj file) written in XML declarative syntax and executed by MSBuild/dotnet.exe
• A normal WixSharp process is based on the build script (cs file) written in C# procedural syntax and executed by MSBuild/dotnet.exe (in the post-build event). That's why you can even execute the build script without VS. Execute it as a true script with CS-Script, which was the historical approach for build execution and it gave the name "build script".

You can read more about it here: https://github.com/oleg-shilo/wixsharp/wiki/Managed-Setup-Model#building-and-running-msi

The major difference is that with WixSharp build script you do not have to rely on any project settings even though it's possible.
You can pass any settings to the script via CLI args, envars or any other mechanism (e.g. read registry) that otherwise is not available in the limited syntax of MSBuild. IE

if (Environment.GetVariable("Is64Build").Any())
    project.Platform = Platform.x64

// or
if (args.Contains("-x64"))
    project.Platform = Platform.x64

The build script has to be compiled with AnyCPU or x86 if it implements any custom actions. This is because MSI can only load x86 DLLs because it's never a x64 process.

Thus if you do not implement any custom action then you can even do something more directly based on the project settings:

project.Platform = Environment.Is64BitProcess ? Platform.x64 : Platform.x86; 

BTW, I overlooked another Files constructor signature that gives you a simpler statement:

new Files(@"..\Release Folder\x64\*.*")
{
    OnProcess = file =>    
        file.Condition = new Condition("VersionNT64");
},

---

What has been tricky is looking at the problem top-down (WixSharp syntax to generate XML) and bottom-up (Wix XML syntax needed for correct MSI generation).

You nailed it on the head. This is exactly the difference between the WixSharp and WiX philosophy.

WixSharp encourages you to go from the requirements to the behaviour implementation in the well-known Syntax. IE "I want to check the registry before the installation". So "I will use C# to analyse the registry in the BeforeInstall event". Ideally you should never even know about MSI tables and things like "MSI Properties" or "deferred actions".

WiX on the other hand asks you to think in MSI tables, UISequences, CustomActions and binary files those actions are implemented in. IE 'registry sample' I need to create a property, and then I need to schedule the read registry operation for this property. If it's some tricky access I may need to bring a WiX extension. If something is not available out of the box then you need to hope that someone else has implemented the WiX extension for this.

You can check this interview on InfoQ. It covers the matter well.

[frnds1]

Thank you. I've created a matrix to map which installs have requirements that are best served with managed MSI, unmanaged MSI (simple copy files), and Bootstrap.