Modify existinig WIX 2 script to add 64-bit components - winapi

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).

Related

How do I unify two msi installation packages (64bit and 32bit) created by Windows Installer into one?

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/

MSI Installer for 64bit Windows Platform(Visual Studio)

I have a COM component which I wish to deploy in a 64bit environment. There are multiple applications using this COM component. Some of these applications are 32-bit and others are 64-bit.
So while creating an installer, I which to bundle both the 32-bit and 64-bit versions of my COM dll.
In my first attempt, while building the installer project, I get a lot of warnings:
Ex. WARNING: Two or more objects have the same target location ('[payload_ul]\msvcp90.dll')
The warnings above are to do with merge modules. I have checked, but no multiple merge modules are present.
Also while the projects compiles successfully though with the warnings, while testing I found that the 64 bit module had failed to register.
The MSI was marked for x64 platform.
Can anyone provide pointers for the correct way to do this?
MSI doesn't support mixed x86 and x64 installers (check out this blog: http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx ). There are ways to "workaround" it, but eventually you will be bitten one way or another.

Do I have to make allowances for Inno setups on 64-bit Windows?

We've got an ancient of days VB6 app which sometimes needs to be updated and installed on our user's machines. We've begun using Inno, and especially InnoIDE, to make the setup.exe, to get this onto our user's PCs. However, I'm wondering about 64-bit Windows, and Inno setups. We've got a couple of machines in-house, which are 64-bit versions of Windows 7 Professional. I've successfully installed our app, using the setup from Inno, onto a 32-bit Windows XP machine. Can I use the same setup on our 64-bit Windows 7 machines? Will it put the .exe into the C:\Program Files (x86)\ directory structure automatically, or do I have to make allowances for 64-bit versions of Windows?
If your app is only 32-bit, then Inno will automatically take care of doing everything correctly.
Only if your app is mixed or 64-bit do you need to do anything special as rushman says.
There is a very good section in the help file that explains the changes needed.
If you're installing any 64-bit device drivers, the calls to most newdev and setupapi entry points will fail with error code 0xE0000235 (ERROR_IN_WOW64). Those calls only work when invoked from 64-bit code, and Inno doesn't compile 64-bit installers yet. You may work around by using pnputil.exe, by adding a 64-bit stub executable, or by switching to WiX.
For 64-bit INNO intallations you generally only need to add one setup section directive and, obviously, add the 64-bit versions of DLL's and EXE's to the compiled installer.
The setup section directive is:
ArchitecturesInstallIn64BitMode=x64

Windows Installer: can two different installer share the same componet

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.

Install VC++ Runtime 64-bit if system is 64-bit

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.

Resources