Installing incorrectly as 32 bit installation
Posted: Thu Nov 03, 2016 10:49 am
Hi,
We've recently encountered an issue with an install on a customers environment.
The installation in question is a 64 bit, it should exit if it is not able to set the x64 mode, and the components that are installed need a x64 environment to function correctly. There are no rogue Set X Mode commands in the script that could change the installation mode.
The problem is that this customer's installation is getting installed as a 32 bit application. So instead of getting installed into the C:\Program Files\Company\Title folder, as is specified in the targetdir window, WIN64DUALFOLDERS redirects most of the installation to the C:\Program Files (x86)\Company\Title folder, and the application gets registered in the 32 bit part of the registry. We have the installation logs, and even though there are differences between his and a typical installation, nothing else stands out.
The few files we create during the installation are created in the 64 bit folder. The shortcut points to the 64 bit folder, altough there's nothing there to point at. Starting the application from the installation finished dialog ends with an error since TARGETDIR is still pointing towards the 64 bit Program Files location, even though that is not where the application's exe is located.
The customer can freely copy the contents of one folder to the other and the application will work, but the upgrade and uninstall won't (since the installation has no idea where all the files are).
The customer can replicate this issue on at least a few other machines, all WS 2016, all recently upgraded from a prerelease build to RTM. We could not replicate this behaviour on our WS 2016 machines, but we also can't get our hands on the exact same versions.
Is this a known issue? Is there anything we should be looking at or doing differently to prevent this behaviour?
We've recently encountered an issue with an install on a customers environment.
The installation in question is a 64 bit, it should exit if it is not able to set the x64 mode, and the components that are installed need a x64 environment to function correctly. There are no rogue Set X Mode commands in the script that could change the installation mode.
The problem is that this customer's installation is getting installed as a 32 bit application. So instead of getting installed into the C:\Program Files\Company\Title folder, as is specified in the targetdir window, WIN64DUALFOLDERS redirects most of the installation to the C:\Program Files (x86)\Company\Title folder, and the application gets registered in the 32 bit part of the registry. We have the installation logs, and even though there are differences between his and a typical installation, nothing else stands out.
The few files we create during the installation are created in the 64 bit folder. The shortcut points to the 64 bit folder, altough there's nothing there to point at. Starting the application from the installation finished dialog ends with an error since TARGETDIR is still pointing towards the 64 bit Program Files location, even though that is not where the application's exe is located.
The customer can freely copy the contents of one folder to the other and the application will work, but the upgrade and uninstall won't (since the installation has no idea where all the files are).
The customer can replicate this issue on at least a few other machines, all WS 2016, all recently upgraded from a prerelease build to RTM. We could not replicate this behaviour on our WS 2016 machines, but we also can't get our hands on the exact same versions.
Is this a known issue? Is there anything we should be looking at or doing differently to prevent this behaviour?