1

I have a WiX installer that can be built as a 32 bit or a 64 bit installer, with some preprocessing to select between ProgramFilesFolder and ProgramFiles64Folder.

Since the installer places some files in the Shared Documents Folder and Common AppData, the two versions cannot co-exist side by side and so have the same Upgrade Code and different Product Codes.

RemoveExistingProducts is scheduled early, immediately after InstallValidate and I always perform a major upgrade between releases.

However, when an upgrade is performed from an earlier x64 version to a later x86 version, all the x64 files in c:\Program Files are left behind.

Reading the logs, it appears that when it comes to uninstall the older x64 components, it is looking in c:\Program Files (x86):

MSI (s) (50:08) [11:53:16:589]: Executing op: FileRemove(,FileName=common.dll,,ComponentId={1680271B-6AAD-4B2A-8F6E-BDCBC964CC92})
RemoveFiles: File: common.dll, Directory: C:\Program Files (x86)\XJTAG 3.5\Bin\

Originally, the components in both installers had the same GUIDs even though they are being installed into different locations in the two installers, knowing that scheduling RemoveExistingProducts early should allow me to get away with it. However, I built a new 32-bit installer with different GUIDs and the problem remains.

It doesn't happen the other way around. It seems that because the new version is a 32-bit installer it is using c:\Program Files (x86) rather than c:\Program Files.

Is this kind of upgrade just something that is impossible?

PhilDW
  • 20,260
  • 1
  • 18
  • 28
John Hall
  • 535
  • 5
  • 15
  • 1
    I haven't tested this, but I suspect this upgrade won't work because the uninstall of the older 64-bit product is being called from a 32-bit install, so you could get the WIN64DUALFOLDERS thing going on, prohibiting access to native Program Files. A closer inspection of the log might show this. – PhilDW Feb 02 '17 at 17:53
  • 1
    I thought Major Upgrades couldn't switch between per-user/per-machine and that they couldn't switch between 32/64bit platforms also. I would think a bootstrapper chain would be needed to make this type of transition. Or just force the user to do a full uninstall. – Christopher Painter Feb 03 '17 at 02:59
  • @ChristopherPainter that may very well be true, I just couldn't find any discussion of it. – John Hall Feb 03 '17 at 09:16
  • @phil I think you're correct as to what is happening and explains why upgrading from 32-bit to 64-bit does work. I guess I imagined that because a component is marked as 64-bit, MSI would handle it appropriately. – John Hall Feb 03 '17 at 09:20
  • I'm not sure either. I might be misremembering this or I might not. There was a time that I'd push MSI to it's limits and now there are well worn paths that I tend to stay in for productivity and quality reasons. Please post your finding as it'll help refresh the KB articles in all of us old guys. – Christopher Painter Feb 03 '17 at 11:31

0 Answers0