I am creating a Visual Studio 2010 Setup project for installing my application. My application works by having multiple executable for different system bitness, and detects if you are running on a 32-bit or 64-bit system.
I'd like to have the Visual C++ 2010 x64 Runtime installed by the installer if it is a 64-bit system. Setting this as a prerequisite, disables installation on 32-bit systems. Is there any way to set this as a prerequisite, but only on 64-bit systems, without resorting to two different installers?
You need to create separate MSI files for the 64-bit version and the 32-bit version to deal with the specialities of WOW64.
It is not possible to have one single MSI install both a 64-bit and a 32-bit version:
Different Packages are Required for Different Processor Architectures
Because you will have separate MSI files it should be easy to add the 64-bit VC++ Runtime Redistributables to the 64-bit MSI and the 32-bit ones to the 32-bit MSI respectively.
Of course, you may create a bootstrapper that checks the system architecture and then launches the respective MSI file. I believe dotNetInstaller offers such a mechanism as has been indicated in a related question.
Related
I created 32-bit and 64-bit installation files respectively with Windows Installer. How can I create a unified installation file that can check the bits during installation, and merge these two into one to install automatically according to the bits?
Heath Stewart: Different Packages are Required for Different Processor Architectures. Here is an extract: "A common question is how to create a Windows Installer package that installs 32-bit binaries on 32-bit platforms, and both 32- and 64-bit binaries on 64-bit platforms. If you’re actually trying to install 64-bit binaries to appropriate directories and write to the 64-bit view of the registry, the short answer is that you can’t build a single package."
You should be able to use a setup.exe creation tool such as WiX's Burn or Advanced Installer or InstallShield (all can create setup.exe launchers). I am unsure of the built-in mechanisms they provide for this at the moment - I haven't looked at it for a while.
In any case you need a 32-bit setup.exe so that it can launch on both 32 and 64 bit systems and inside it you can keep your 64-bit setup along with the 32-bit one.
Rob Mensching's on the topic: How to deploy 64-bit and a 32-bit Windows Installer package as a single setup?.
Here is one of his blogs on Burn: https://robmensching.com/blog/posts/2009/7/14/lets-talk-about-burn/ and here is the normal starting point in the WiX documentation for Burn.
Here is my attempt to show a basic, functional Burn package (many links - too many - towards the bottom).
Links:
Single MSI to install correct 32 or 64 bit c# application
https://www.firegiant.com/wix/tutorial/net-and-net/bootstrapping/
I have an add in for Microsoft Word, if I launch it from Visual Studio it open and run correctly but when I try to build and install the .msi on a 64 bit windows 7 I have a problem.
The installation end fine but when I try to open the add in, Word raise an error because it search for the add in in x64 programs file and not in x86 folder. I want that the add in is installed only in x86 programs file and I have specified as Target platform x86 and defaultLocation [ProgramFilesFolder][Manufacturer][ProductName].
What is the error?
There are 32-bit and 64-bit versions of Office, so the most likely cause of this issue is that the user has installed 64-bit Office. That means that it must look in the 64-bit locations because a 64-bit process cannot load a 32-bit Dll. You're referring to the x86 locations, so I'm assuming that your code is 32-bit.
If you don't want to support 64-bit Office then you'll need to detect when there is a 64-bit Word or Office on the system and stop the installation. If you do want to support 32 and 64-bit Office then build your 32-bit one, and then build another MSI with 64-bit target location, 64-bit code, and 64-bit folders such as ProgramFiles64Folder. Your users install the appropriate one for their Office architecture version.
I'm making installers for plug-ins using the InstallShield LE built in to Visual Studio 2010. The plug-ins run in separate processes, so they are always 32-bit even if the host application is 64-bit. The plugins must be installed to the same directory as the host application. Therefore, the plugins should always install in Program Files even on 64-bit Windows - not Program Files (x86).
InstallShield's [ProgramFilesFolder] predefined folder detects that the project output is 32-bit and evaluates to Program Files (x86) on a 64-bit machine.
I thought I could get around this by using a fixed folder instead of [ProgramFilesFolder]. But Installshield appears to change it to Program Files (x86) anyway! I guess it's trying to be helpful.
Is there any way to get around this?
The redirection is done by the OS, not by InstallShield. The same applies for MSI packages built with other setup authoring tools. I explained this with more details in
How to install VS help using WIX x86 installer on a x64 platform?
I have two installers - one for 64-bit Windows and another for 32-bit Windows. The 32-bit installer installs 32-bit executable and DLls, while the 64-bit installer installs 64-bit exes and dlls as well as the 32-bit ones. The 32-bit components are shared by both installers.
Does Windows Installer explicitly allow this scenario? Thanks.
Yes, this is supported. Just make sure that the 32-bit components have the same names and GUIDs in both installers. This way a reference count is used for them.
I have an installer script written in Wix 2 several years ago. Now I need to add two 64-bit components. One 64-bit DLL to be copied to system32 folder and another b4-bit EXE to ProgramFiles.
The installer needs to create registry key. Currently it uses a element to write a key, and a custom action (in 32-bit MSI dll) to write the serial number.
The key must be accessible to 64-bit EXE.
Is it possible to do in one MSI? Also how to create a condition that only copies the 64-bit files when the system is 64-bit?
msi doesn't allow installing 32-bit and 64-bit components in the same msi. You have to create a separate msi for both architectures.
In order to install 64-bit components, the MSI needs to be marked as being 64-bit - otherwise, filesystem and registry paths will be redirected. As well as adding the 64-bit attributes, the 32-bit and 64-bit packages should appear as different products; i.e. you should create new Product and Upgrade codes.
I think there may be problems with using WiX 2 to create 64-bit MSIs, so you may need to upgrade to WiX 3.x.
Since you need two MSI files for 32-bit vs. 64-bit Windows, you can easily prevent 32-bit files being installed on a 64-bit PC by not including them in the 64-bit installer. If you need a single installer executable for both x86 and x64 you'll need to use a bootstrapper which chooses which MSI to run. I don't know if burn.exe from the WiX distribution can do this.
One way to approach the source layout is to use a single master WiX file with conditionals which select which features to build in depending on the target architecture, and then have architecture-specific modules which get linked in. You can find an example of such a solution at https://svn.bluestop.org/viewvc/repos/sctpDrv/wix/ . Note that it only supports x86 and x64 and not Itanium (aka Intel64).