installing 64 bit does not cleanup old x86 installs, and installs in wrong place

[Glowsome]

Describe the bug When having an x86 client on a x64 OS and upgrading to an x64 version the old path is used again.

Steps to Reproduce Steps to reproduce the behavior:

1. have an older x86 client installed in c:\Program Files (x86) ( fully functional
2. get new x64 client and run install.
3. path to x86 client is re-used, instead of installing the x64 client in c:\Program files*
4. this is an issue when you automate deployment.

Expected behavior If a new client is deployed ( and switches from like say x86 to x64 architecture it should uninstall the old (different arch) client. Then it should deploy the client in the correct/expected location, so if one goes from an x86 client to a x64 one, it should be installed in c:\Program Files* .. and not re-use the old path leading to c:\Program files (x86)*

Screenshots

Desktop (please complete the following information):

• OS: any wintendo running 64 bit
• Version: 1.3.2 mumble ( i have not tested older clients, but had x64 previously, but also a x86 1.2.19 still somewhere.

Additional context Req : also add a reccomendation to install where the installer checks architecture, and advise accordingly as an additional step ( as in 'hey you are trying to install a x86 client on a 64 bit system, we advise you to use the 64 client version of mumble .

[Krzmbrzl]

Does other 64bit software on Windows remove previously installed 32bit versions of itself? I wouldn't expect this.

Anyways as far as I know the cleanup of old versions etc. is not even handled by us. This is all done by windows (via the installer framework).

However I think that our problem is that we package our 64bit binaries the same way as the 64bit ones. Thus the installer always considers them to be x86 which is why it gets installed in the wrong dir.

Reference for fixing this:

• https://stackoverflow.com/questions/4304253/how-do-i-get-wix-to-generate-a-64-bit-msi
• https://stackoverflow.com/questions/6231950/using-wix-to-create-32bit-and-64bit-installers-from-one-wxs-file
• https://stackoverflow.com/questions/471424/wix-tricks-and-tips/577793#577793

[Glowsome]

In regards of my ways of deployment (i use Novell (nowadays Microfocus) ZCM ) i can chain in an uninstall of any previous client to be executed prior to installing a new client. The thing i'm afraid of is that with running such a scenario i will also erase registry entries on a/the client ... One example i found out is the personal setting of "Text-to-speech" which apparently is not saved and thus one is confronted with it being switched on again after upgrade.

=> i could impose ( in my setup ) these registry settings, but i am sort-of "out of the ordinary" with my deployment/setup so i could assume that this behavior isn't wanted for others.

[ghost]

Windows itself supports side by side installs of 32 bit and 64 bit. It also stores each bit level registry keys in their own registry areas. This would mean that a 32 bit installer would not be affected by a 64 bit installer, and vice versa. Are you scripting the install as an upgrade or an install? You will probably want to do a remove/uninstall of the 32 bit then an install of the 64 bit in your script. Windows Installer should also warn you that you will not be able to install a 64 bit program on a 32 bit system already. Are you seeing a specific issue where this is not the case?

[Glowsome]

As stated the case is having a 32-bit client installed (from legacy previous versions), but as the machine is running a 64-Bit OS it is wise to also have them running a 64-bit client.

To answer your question - it is defined as an install, but apparently an /MSI has some of logic in it that detects other installed versions ( either 32 or 64 bit) and then imports known paths from it and then performs an upgrade.

Some indication : https://i.imgur.com/R9qKTLb.png

[ghost]

I believe the issue is here:

https://github.com/mumble-voip/mumble/blob/bca041e2b27d73a28a551faaeef082278a194fce/installer/Settings.wxi#L7-L26

I see where there is a check for the bit level to assign the upgrade GUID but I don't see where a unique GUID is assigned for the installer bit levels. I may be looking in the wrong place, however.

[Glowsome]

@ZeroAbility i am no MSI expert, but would a thing be possible as in ( logic) Depending on the msi package being run : if OS == 64bit {Check 32Bit install} if present => announce if installing 32-bit version, prefer 64-bit. if user still wants 32-bit -> go install 32-Bit. exit; else if (trying to install 64-bit) => uninstall 32bit version. => install 64bit new package / ignore previous paths detected, honor 64-bit paths fi fi bit of a crude way hope my message comes across :)

[ghost]

I don't believe we bundle both 32 and 64 bit into the same installer which is where that would be a factor.

https://www.mumble.info/downloads/

The GUID that gets registered for 32 and 64 bit should probably be unique and a good use case to have both installed would be for testing. Most normal use cases would see one or the other. To work around the issue for now it would be best to add to your script logic that would check the Program Files(x86) path for the presence of Mumble and attempt an uninstall. Then install the 64 bit msi.

If you are scripting installers through GPO or the like, 32 or 64 bit system can be checked using PowerShell or WMI. As far as I know, a 64 bit installer will be flagged and the warning you are suggesting would be automatic if you try to install it on a 32 bit system. The 32 and 64 bit paths are configured here, are based on the build configuration, and assigned at compile time:

https://github.com/mumble-voip/mumble/blob/bca041e2b27d73a28a551faaeef082278a194fce/installer/Settings.wxi#L7-L15

[Krzmbrzl]

@ZeroAbility could it be though that the BUILDARCH variable is not set properly? From the snippet you linked I would expect the 64bit version to be installed in the proper program files directory. However apparently it is also installed in the 32bit directory... Or maybe this is only for upgrades from 32bit to 64bit? And thus after all it is related to the GUID thingy? :thinking:

[ghost]

I found this which also seems to support using separate GUID's for each platform installer:

https://stackoverflow.com/questions/1405100/change-my-component-guid-in-wix/1422121#1422121

I think $(sys.BUILDARCH) is just an env var that returns the x86 or x64 depending on which one is set in the Visual Studio configuration.

[Krzmbrzl]

So this does indeed suggest that the problem is that we're using the same GUID :thinking:

[Kissaki]

Depending on the effort it may not be worth fixing this behaviour. The two Windows program folder have no functional difference. It may be confusing to a user who checks the installation path. But a (manual) uninstall and install will clean it up.

Over time with people installing it fresh/on a fresh system this issue will be less and less prevalent.

Using a new/different guid and uninstalling by the old guid may be the clean solution here, if that is possible. But that also means 64 bit installers will have to transparently handle previous 64-bit with the old guid installs. It would have to construct a new path if the old one was program x86, but not if it is a custom path.

[ghost]

@Kissaki - I agree. In most system administrative tasks like this when scripting an MSI install that goes from x86 to x64, the best practice is to remove the x86 version and install the x64 version. A small argument could be made to add a unique product GUID when x86 is detected for that installer but they probably shouldn't be installed on the same system even for testing since the icons are labeled the same and could cause confusion.

[Krzmbrzl]

For the reasons stated above, we will not fix this issue. In the end we think the effort needed to fix this is just not worth it.

If you are bothered by this, perform a manual uninstall before re-installing Mumble. After that the program should be installed in the correct program directory :)