Move application from "Program Files x86" to "Program Files" when upgrading to 64 bit version

Question

App was initially delivered in 32 bit form. Now it is distributed with 32 and 64 bit version.

Now when user on 64 bit Windows upgrades application from 32 bit version to 64 bit version default installation folder should point to "Program files" (no x86).

I've updated my wsx files in such way:

    <?if $(var.Platform) = x64 ?>
        <?define bitness = "(64 bit)" ?>
        <?define Win64 = "yes" ?>
        <?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
    <?else ?>
        <?define bitness = "(32 bit)" ?>
        <?define Win64 = "no" ?>
        <?define PlatformProgramFilesFolder = "ProgramFilesFolder" ?>
    <?endif ?>
      ....
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="$(var.PlatformProgramFilesFolder)">
                <Directory Name="COMPANY" Id="D.COMPANY">
                    <Directory Name="Product name" Id="APPDIR">

                    </Directory>
                </Directory>
            </Directory>
        </Directory>

And this works nicely for fresh installs:
When 32 bit app is installed on 64 bit system it is installed in "Program files x86" and in all other cases installation is performed to "Program files".

In case of upgrade from 32 to 64 bit default destination folder is still "Program files x86" and I like that if it is moved to "Program files".

Is there a nice way to do it? Or do I have to override this some custom action in my C++ code?

Edit/Update:
Just to be clear. My application is a background service. Machine user doesn't see that application at all (except for extreme corner cases). In most of the time this service is installed/ungraded by other service which silently and remotely can install required software.

During this upgrade all 32 bit components are purged (one exe and couple dll-s) and replaced by 64 bit equivalents. Configuration data and cached data are transferred to upgraded application.

RemoveExistingProducts is set to <RemoveExistingProducts After="InstallInitialize" />

How is RemoveExistingProducts scheduled? I am rusty on these bitness / migration issues. OK, now I see you will deliver both versions - originally I read that you wanted to migrate fully to 64-bit. Did you consider installing side-by-side? I will undelete my somewhat relevant answer below so you can have a quick look. — Stein Åsmul

Stein Åsmul Stein Åsmul · Accepted Answer · 2019-05-24T20:03:27

Overall: A couple of issues first:

Side-By-Side: Are you sure you don't want to support side-by-side installation of 32 and 64-bit versions? Different packages with different installation locations (and some shared components)?
- This is sometimes possible - as a transition to the latest version. You can allow both versions to be installed at the same time for some time (or forever).
- It depends how much data your packages install that is "entangled" (globally registered on the machine and hence interfering between packages).
- Here is an answer with a section on side-by-side issues (towards bottom). Not much, but a little bit of discussion on the matter.
Mr. Stewart: I would read this aging, but good blog: Different Packages are Required for Different Processor Architectures.

Practical Bitness: I am rusty, so bear with me, but I would

set a new installation location entirely for your new 64-bit package,
preferably change the product name,
change all component GUIDs (necessary when you move the installation location, explanation here) - use WiX auto-GUIDs if you can,
mark all components that are 64-bit as 64-bit and leave the rest as 32-bit (obviously: <Component Win64="yes" />),
mark the package as 64-bit,
change output file name to indicate 64-bit package,
I might set a new upgrade code to the new version, but that requires more advanced handling of the upgrade table to facilitate uninstall of the 32-bit version. A new upgrade-code is generally necessary to support side-by-side installation. There are many small details... For example: WiX heat.exe does not support 64-bit COM registration data extraction.

Some Issues:

Do you have any remaining 32-bit components? (64-bit packages).
Global scope: Any COM components? Any drivers? Any file associations?
Prerequisites that have bitness issues?

Links:

Move application from "Program Files x86" to "Program Files" when upgrading to 64 bit version

2 Answers