I have a Basic MSI project that is a 32-bit installation. I noticed on 64-bit systems, if the user changes the default install location from Program Files (x86) to Program Files, the installation still ends up under the 32-bit program files. Even when I look in the registry under the Microsoft Uninstall key, the install location is Program Files (x86). I know the WoW64 thing does this automatically. Is this considered good practice though?
Is there a way to override this for the entire installation? Or would it be considered best practices to have it relocate the install to x86 as it currently does?
You could try using [ProgramFiles64Folder] instead of [ProgramFilesFolder] for the Destination property of your component(s). But I think that you would get a compile error (or at least a stern warning) if you did this without also changing the Template Summary (under General Information) to say x64; 1033 instead of Intel; 1033.
But if it is a true 32-bit build, the recommended practice is to install to "Program Files (x86)" and not "Program Files". "Program Files" is the recommended install location for true 64-bit (native 64-bit) builds.
Right. If your package is 32-bit, Windows Installer will rewrite the 64-bit program files folder to the 32-bit path. But if your package is 64-bit, you cannot install it on a 32-bit system. The suite projects in IS2012 help you address this in a single distributable file, but the underlying bit issues still apply to each .msi file.
Okay, thanks. So it would be incorrect, or at least ill-advised, to try to force a 32-bit app to install under the 64-bit Program Files? I just want to be sure so I can explain in case I get back a defect stating the app can't install under Program Files on 64-bit systems...
From our perspective it is a limitation rather than a defect, as it is controlled intentionally this way by Microsoft's Windows Installer. So not technically a bug, but agreed that it's not quite the behavior you were expecting.
