32 bit package with 64 bit resource

[bdube]

Hello,

Is it possible to install a file to (64 bit) C:\Program Files from a 32 bit package?

In Install Parameters I have chosen 32 bit package because the main application I am installing is 32 bit and uses 32 bit file and registry locations like C:\Program Files (x86). Even though the main application is 32 bit, we want the installer to be limited to 64 bit versions of Windows; so in Launch Conditions, I have selected only 64 bit Windows versions. So far, so good. But now I have one 64 bit DLL that I need to install to a fixed path under C:\Program Files\CompanyName, regardless what APPDIR is set to. Is this possible with a 32 bit package type?

I have seen that there is an option for mixed 32 bit/64 bit/Arm64, but I don't think this is what we want because we want the application to be installed to C:\Program Files (x86) even when the platform is 64 bit. And we don't allow 32 bit in Launch Conditions, so mixed mode doesn't seem right.

Thank you,
Brian

[Catalin]

Hello Brian,

I'm afraid a 32-bit package can not write to a 64-bit location, in this case the "Program Files" folder.

The Windows OS simply does not allow that.

We can try to work this around via a custom action.

Here's what I'm thinking:

1. in Advanced Installer, add the files that you require as "temporary" files.

Note: these files are copied on the disk at the start of the installation and removed towards the end automatically (therefore, we will not need to clean this up)

These files will be automatically added under a folder named [|ProductCode] - this property resolves to the product code of your installer (this can be seen under "Product Details" page --> "Product IDs" tab)

Screenshot_163.png (15.6 KiB) Viewed 5155 times

2. we now need to create a script that will work this path out, create a folder under C:\ProgramFiles and then copy the temporary files over there.

To do so, we can create a PowerShell script, because we can explicitly set this to use the 64-bit engine of PowerShell.

The "Parameter values" field of the script should look like this:

Code: Select all

-TempFolder "[TempFolder]" -ProductCode [ProductCode]

We use this to retrieve the two properties required to construct the path of our folder.

And the script itself can look like this:

Code: Select all

#Requires -version 3
Param(
[string] $TempFolder,
[string] $ProductCode
)

$sourceFolder = Join-Path -Path $TempFolder -ChildPath $ProductCode
$destFolder   = Join-Path -Path "C:\Program Files" -ChildPath "testFolder"

if (-not (Test-Path $destFolder)) {
    New-Item -Path $destFolder -ItemType Directory -Force | Out-Null
}

Copy-Item -Path (Join-Path $sourceFolder '*') -Destination $destFolder -Recurse -Force

As you can see, we grab those two properties and then generate the source folder (the folder where our temp files reside).

We then create the destination folder, under "C:\Program Files".

And the final step is to copy the content of the source folder over to the destination folder.

The custom action should be scheduled after "Install Initialize" action:

Screenshot_164.png (8.41 KiB) Viewed 5155 times

and should have a configuration as it follows:

Screenshot_165.png (65.71 KiB) Viewed 5155 times

After install time, the folder should be created and the file should be there:

Screenshot_166.png (16.27 KiB) Viewed 5155 times

As a last note, in my script I have used the hardcoded value for "C:\Program Files", which may not be the best thing to do. Instead, you can try to use env variables which are safer than the hardcoded value.

Hope this helps!

Best regards,
Catalin

[bdube]

Hello,

Thank you for this detailed answer. It appears to be working for us.

Thank you,
Brian

[Catalin]

You are always welcome, Brian!

I am really glad to hear it works as expected.

Best regards,
Catalin