1

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" />

Marek R
  • 32,568
  • 6
  • 55
  • 140
  • 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 May 24 '19 at 20:08

2 Answers2

2

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

  1. set a new installation location entirely for your new 64-bit package,
  2. preferably change the product name,
  3. change all component GUIDs (necessary when you move the installation location, explanation here) - use WiX auto-GUIDs if you can,
  4. mark all components that are 64-bit as 64-bit and leave the rest as 32-bit (obviously: <Component Win64="yes" />),
  5. mark the package as 64-bit,
  6. change output file name to indicate 64-bit package,
  7. 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:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • yes I'm sure it can't be side-by-side app. This is service running in background (no user interaction), so there is no point to double this service. – Marek R May 25 '19 at 17:56
  • Chris mentions that there could be problems migrating from one bitness to another. I have not tried but if you uninstall the old version early and install the new one to a new location I think that should work. I have not tested, always dangerous to state anything for sure without a test case. Has the whole software become 64-bit **only**? – Stein Åsmul May 25 '19 at 18:10
  • bug was reported since this package is remotely and silently installed by some business administration tool. So uninstall/install is not a valid option for me. – Marek R May 27 '19 at 11:49
  • How have you sequenced `RemoveExistingProducts` in your MSI? You can uninstall the old version early as we say (RemoveExistingProducts right after InstallInitialize), meaning that it is completely gone before the new version is installed. – Stein Åsmul May 27 '19 at 11:51
  • I've inherited this stuff (I'm more like MacOS iOS dev, who was asked to fix stuff on Windows). Anyway this entry looks like this `` – Marek R May 27 '19 at 11:54
  • I haven't done this in a long time, but I would set the package 64-bit and include separate components for the 64-bit and the 32-bit components targeting different folders and install both versions at the same time - creating two different launching shortcuts. As simple as possible? I might not understand the whole scenario. You don't need to support installation on 32-bit-only systems do you? Very vintage :-). – Stein Åsmul May 27 '19 at 12:01
1

There was a discussion about this here:

Upgrading application and switching from 64-bit to 32-bit

Basically my first comment is if your a .NET application you can run 64bit even if you were installed 32bit.

My second comment is I don't believe (see comments in other thread) MSI supports doing a major upgrade and changing bitness. It's just not a use case that was foreseen ( example going x86 -> arm or x64 -> itanium ). I believe you'd have to have a burn bootstrapper that handled removing the 32bit MSI and installing the 64bit MSI as part of the bundle.

As for authoring the MSI, ProgramFiles64Folder and ProgramFilesFolder are different directories and therefore different component ID GUIDS.

Another thing to consider is some products are ok to have both 32bit and 64 bit version installed. Case in point would be C++ runtime redists. Maybe it would be acceptable to design to allow side by side install and just put it on the user to remove the old one.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100