Combined 32bit and 64bit installer

[wiggers]

I've found this thread from a decade ago that describes one method:

http://community.flexerasoftware.com/showthread.php?189714-64-bit-vs-32-bit-Installation-Support

I was thinking that by now there should be a much simpler way of doing it. I have an additional complication that on 64bit platforms I need to do different things depending on whether 32 or 64bit MS Office has been installed. So I have one set of components that are platform agnostic, another set that depend on the OS and others that depend on the flavour of Office but only on 64bit Windows.

Are there some clever features in IS 2012 Spring to do this?

[wiggers]

OK, I've found something about 'Suite/Advanced UI project' in the help system. That seems to be the way to go. I have the Premier edition.

[IlkkaV]

Suite / Advanced UI project with two primary packages (one 32-bit MSI and one 64-bit MSI) and the dependencies is exactly the approach I'm using at the moment. Managing the dependencies is much easier and more convenient with the Suite / Advanced UI project, but unfortunately controlling the suite setup UI seems to be more complicated and some stuff that's trivial with an MSI project seems to be hard and/or undocumented at the moment.

[OldBean]

I use IS 2011, it has not such thing as "Suite/Advanced UI project" which comes with IS 2012 Spring.
Early last year, I faced a similar situation where it was required to install different features/components sets depending on the bitsize of MS Office. The complication was that 32bit MS Office can be installed on both 32bit and 64bit Windows where 64bit MS Office can only be installed on 64bit Windows.
I used InstallScript MSI project, I could put 32bit features/components alongside with 64bit ones in one project, but I could not build all features into one installer. It seemed to be the limitation/restriction of MSI not InstallShield. I ended up with 2 installers: a 32bit one targeting 32bit MS Office on both 32/64bit Windows and a 64bit one targeting 64bit MS Office on 64bit Windows.

Please kindly post it here if you can work out a solution (one msi covers 32/64 windows) using IS 2012 Spring, it would be a very good motivation for me to upgrade my InstallShield.

Thanks in advance,

[IlkkaV]

OldBean wrote:

Please kindly post it here if you can work out a solution (one msi covers 32/64 windows) using IS 2012 Spring, it would be a very good motivation for me to upgrade my InstallShield.

You were right about the fact that it's an MSI limitation that a single package can't contain both 32-bit and 64-bit versions. This is still the case with the Suite/Advanced UI project. The Suite/Advanced UI project is rather limited in functionality (e.g. custom actions are missing) and it's mainly for grouping a set of separate installers and dependencies into a package that looks like a single installer from the user's perspective. In the background most of the heavy lifting is still done by the old MSI/InstallScript MSI/whatever installers. So while the Suite / Advanced UI project does not actually get around MSI limitations, to the users it looks like it does and they don't have to worry about selecting the correct package.

I'm also working with a project that depends on Office, and having 32-bit/64-bit versions of the VSTO runtime in the mix makes it quite complex to manage with the prerequisite capabilities available for MSI projects. I was really happy when I could rip the prerequisites out of the MSI packages and let the Suite installer take care of that part and have the MSI projects only install the actual software. Now if only I could find a good way to implement some of the UI logic/functionality I had in the MSI versions I'd be really happy.

[wiggers]

It sounds like having multiple installers with each set of components that are required for each target configuration is the way to go. So one installer for all the platform agnostic parts and then one for 32bit Windows/32bit Office components, one for 64bit Windows/32bit Office and so on.

[wiggers]

Has anyone worked out how to determine whether 32- or 64-bit Office is installed on Windows 64?

[wiggers]

wiggers wrote:
It sounds like having multiple installers with each set of components that are required for each target configuration is the way to go. So one installer for all the platform agnostic parts and then one for 32bit Windows/32bit Office components, one for 64bit Windows/32bit Office and so on.

I'm struggling to see how this can be done in Advanced UI/Suite, particularly for the platform agnostic parts. Suite requires MSI packages but has no way as far as I can see of determining the installpath. So the 32 and 64bit packages will have their paths predetermined, but how do I get the agnostic packages (80% of the payload) to follow in the correct location? Do I have to duplicate all the agnostic components in each of the 32 & 64bit packages?

[MichaelU]

You can approach this sort of thing in at least two different ways:

• Add logic to your platform-independent .msi which detects the location used by either preceding platform dependent .msi
  
• Add a page to your Suite/Advanced UI project's wizard that requests the target path and pass it to all interested .msi packages. You can use the User Interface Wizard (access it via the context menu on the Wizard Pages node: "Add Predefined Page...") to add this fairly easily.
  

Note that due to the way Windows Installer is implemented, your platform-independent parts will have to either be installed to a 32-bit-friendly location, or will only install on 64-bit systems. Thus if you need to choose a 32-bit or a 64-bit location depending on the target platform, you may be better off with duplicating these files into the 32-bit and 64-bit platform-dependent packages instead.

[wiggers]

MichaelU wrote:
You can approach this sort of thing in at least two different ways:
- Add logic to your platform-independent .msi which detects the location used by either preceding platform dependent .msi

How do you do that? The only way I've seen a location being assigned is either the default built into the package or something the user selects in the Wizard.

MichaelU wrote:
pass it to all interested .msi packages.

Again, how do you do that? Please can you give a reference in the User Guide/help system that describes this process. There are so many places in the IS Help where it says X, Y and Z are possible, but completely fails to tell you how!

[MichaelU]

The first you would implement inside the second package, somehow querying for an indication of the other package. For instance you could use a system search to query a registry key laid down by the platform-dependent package.

The second you would implement in the Suite UI. In the Wizard Interface view, right click Wizard Page and select Add Predefined Page. Choose Browse for Installation Folder and schedule your page somewhere like before MaintenanceWelcome. Pick one of the packages involved and complete the wizard. You will see it has done three things:

• created a property ISInstallDir_packagename in the Property Manager that provides a default location,
  
• created a page that lets you update the value of ISInstallDir_packagename, and
  
• added INSTALLDIR="[ISInstallDir_packagename]" to that package's MSI Command Line and MSI Silent Command Line settings of the Install operation.
  

You can then add something similar to the command lines of your other packages, and possibly choose a different default location.

[wiggers]

MichaelU wrote:
The first you would implement inside the second package, somehow querying for an indication of the other package. For instance you could use a system search to query a registry key laid down by the platform-dependent package.

OK, I've got a system search and assigned the folder to a Property. How do I set INSTALLDIR to be that value? INSTALLDIR only exists in the Directories table and I don't know of a mechanism in a Basic MSI for changing that.

[MichaelU]

All entries in the directory table map to properties at run time. So depending on when you set this (before or after CostFinalize), you can use either a set-property or a set-directory type of custom action.

[wiggers]

Just had an email from Flexera about top blog articles and the first one is a solution to the 32/64 problem from 2011!!!

http://blogs.flexerasoftware.com/installtalk/2011/01/building-32-bit-and-64-bit-installations-from-the-same-installshield-project.html

[Thomas_Hübner]

Hello,

I already created two Installations (one for x86 and another one for x64 platforms).

The installation files are stored in cab files (one per feature). The 64-bit features have a different file name (xxx64.cab). We have some features which are completely the same in both installations. These will be included twince on our DVD (in each setup). Now I'm looking for a way to combine both installations in one directory, so that I can optimize the size on a DVD.

The target directory should content:

• one MSI and Setup.exe for 32-Setup
  
• one MSI and Setup.exe for 32-Setup
  
• a set of 32-Bit cab files (for 32-Bit features in both installation)
  
• a set of 64-Bit cab files (for 64-Bit features, which only will used in 64-Bit setup)
  
• a separate EXE (which we already have) to choose the right setup depend on the OS.
  

A Suite-Installation is not a solution, because the final file structure has two separate directories with duplicate cab files and the UI is not customizable like the InstallScript MSI project.