Can we create 1 project with 1 output exe which supports both 32bit & x64 OS's ?

[BrHartmann]

I know this was either very complicated or impossible in prior releases of Installshield, but we were under the impression this capability was greatly enhanced in IS 2011, and have recently upgraded to take advantage of this. So far, between the release notes and forums I haven't seen clear instructions on how to accomplish this.

To clarify, I'd like to maintain a single project (ideally using installscript MSI) which creates one output exe that could be installed either on a 32-bit or x64 OS. I've seen explanations involving setting release flags (where 32b/x64 components are filtered accordingly) and generating 2 separate output exe's. Is this the best available option even with IS 2011?

Some details about what we have now which may help clarify what we need:
-- both our 32b and x64 installers have dlls installing to the GAC (needing to be registered during install), to system32, and writing lots of registry keys in the HKLM branch.
-- the x64 installer includes some 32-bit applications with accompanying registry keys meant for the WOW6432Node area of HKLM. These are generally duplicates of some of the x64 applications, and so there is no equivalent need in the 32-bit installer for these duplicates.

While I expect certain files would need to be duplicated in 32b and x64 components, a great many of our files are exactly the same for both installers and we would really like to minimize the installer package size and not have duplicates of these files.

I would really appreciate some guidance in understanding what our options are. Can we accomplish what I've described, or if not, what are the next best options?

Thank you.

[Mescalero]

I too am curious about whether this functionality exists. I made a point of writing this down when it was mentioned during the IS 2011 webcast, but it's not mentioned in the release notes (unless I am overlooking it), and the Template Summary still states "you can specify only one processor value."

Can someone please clarify? Thanks as well...

[KathyMorey]

If I understand this correctly, this is not a limitation of InstallShield, but a limitation of Windows Installer. An MSI package must be marked as either a 32-bit or a 64-bit package, so you can't build a single package that can be installed on either OS.

What you can do, is create a single InstallShield project that will support both, using the release flags to include 32-bit and 64-bit components as appropriate. You will still have to build the package twice, once for each OS.

[Mescalero]

Thanks, Kathy.

So I wonder what the heck they were talking about during the IS 2011 webcast? Doesn't sound as if anything related to this aspect of the product is different from IS 2010.

[BrHartmann]

Kathy - thanks for the clarification about the Windows Installer limitation.

I am not so concerned about fitting 32 and 64-bit files into a single project, but more with the end user experience. We would like to provide a single exe file for customers, so it sounds like we probably would need to strip down the main launcher project and have it detect 32/64 bit and then install the appropriate additional .msi file using the "chained .msi packages" feature.

If there are other alternatives that people know of, please share your thoughts.

If we are left with the chained .msi packages as the best/only solution, that still leaves an additional problem -- this technique (as I understand it) will result in multiple entries in the end user's ADD/REMOVE program list, which leaves the installation prone to user confusion/error. I was wondering if anyone has an elegant workaround for this? Ideally, it would be nice to hide the additional ARP entries beyond the outer "launcher" product, and configure the uninstallation to remove the additional chained .msi packages. I'm guessing this involves deleting some ARP-related registry keys though which are required to correctly uninstall the additional .msi packages. Has anyone implemented a solution like this?

Thanks.

[Shuttledude]

The way I currently handle this is to produce separate install packages (one with a template that targets 32-bit and the other with a template that targets 64-bit), and use an external "Install Wizard" (C# Visual Studio program I wrote) that examines the OS and automatically launches the appropriate install package. That avoids the extra entries in Add/Remove Programs. Also, the user doesn't have to worry about selecting the appropriate install package.

Another approach would be to produce seperate install disks, each with a label that clearly identifies what OS it is intended for. If the user accidentally tries to use the 64-bit disk on a 32-bit OS, the installer will automatically disallow this. And you could add a custom action to the 32-bit installer to prevent the customer from using it on a 64-bit OS.

I have not yet used the 64-bit build enhancements in IS2011, but it's my understanding that it's a "Release Flags" trick and nothing more ... i.e., no way to produce a single release build that auto-detects and automatically installs the "right" way for either OS.

[Mescalero]

Sorry if this is a silly question, but how do you distribute this to users? Does your C# app contain the different setup files, or do you distribute them in parallel?

I currently distribute three separate setup files (targeting x86, x64, and IA64) per app, and the user cannot execute the "wrong" one, but a simpler, cleaner environment in the distribution media would be nice.

Thanks for the great feedback.

[Shuttledude]

The C# app is merely a "wizard", which contains dialogs with checkboxes, one checkbox per product (App1, App2, etc.). So, after the user selects one or more checkboxes and clicks an Install button, the wizard launches the setup.exe program (or the *.msi, as necessary) for each selected application. For some apps, there are 32-bit and 64-bit setups on the DVD. The wizard examines the "bitness" (for lack of a better word) of the operating system, and launches the appropriate setup. If only a 32-bit version of the install is available, that one is chose by default.

So, every user gets a DVD that has each type (32 bit and 64 bit, if available) of setup for every product, and the wizard automatically picks the right one.

I should mention one other thing. Some of our programs have unique versions for XP, Vista, or Windows 7. I.e., the C++ or C# code itself is unique to that operating system. Thus, I actually have to create separate XP, Vista, and Win7 install packages for each App. These are gathered together (all XP, all Vista, or all Win7) onto a DVD targeted that that particular OS. So, there's a DVD for Vista (32-bit as well as 64-bit), and a separate DVD for Win7 (32-bit as well as 64-bit). The wizard also makes sure that if they try to use a Vista DVD, it's on the Vista OS or it won't launch any of the programs they select. Whew! 😄

[Mescalero]

Hey thanks! This sounds like a great solution, short of having a single setup file supporting all processors.

Thank goodness I only have to worry about the processor support, and not the Windows version as well! 😉

[BrHartmann]

I like the C# "wizard" concept... my only concern there is that we currently include .NET 3.5 sp1 as a prerequisite. I know it's included in Windows 7 already, but we still need to cater to pre-Windows 7 users. If .NET is not installed on the target machine, the wizard would fail, right? Or do you have a wrapper to detect & handle this case?

I'm still curious if anyone is using the chained MSI approach with tricks to handle the extra ARP entries?

Thanks.

[Shuttledude]

For Windows XP I have C# code that launches the .Net install for version 3.5 with Service Pack 1. I also install the hotfixes later on, using similar code.

Unless you are forced for some reason to manually install .Net with a C# wizard, it's easiest if you just insert .Net as a prerequisite in the application installations themselves. When the wizard launches those installations, the prerequisite will install, same way as if the user launched the install by double-clicking in Windows Explorer. If you have two or more setups (say, products "B" and "C") that have the .Net framework as a prerequisite, that's not a problem either ... B will install the .Net prereq, and C will "see" that the prerequisite is already installed, and automatically skip it. So it doesn't waste time.

But if you have *many* installs, each with its own .Net 3.5 prerequisite included, then each setup will be very large just because it has to drag along its own copy of .Net 3.5 (over 200 Megabytes). I had so many of these it would barely fit on the media we send (!) so I had to strip out the .Net prerequisite from all the application setups, and just manually install it "up front" via the C# wizard. That way I only had to include 1 copy of the .Net setup on the DVD.

Here's some wizard code if you're interested.

       string curdir = Directory.GetCurrentDirectory();
       string setupfile = curdir + String.Format("\\FRAMEWORKS\\dotnetfx35SP1.exe");
       string args = String.Format("/qb /norestart");
       LaunchProcess(setupfile, args);
       .
       .
       .
       public void LaunchProcess(string setupfile, string args)
       {
            // This function instantiates and starts a setup process,
            // and waits for it to finish.

            if (File.Exists(setupfile) == true)
            {
                System.Diagnostics.Process objProc = new System.Diagnostics.Process();
                objProc.StartInfo.FileName = setupfile;
                objProc.StartInfo.Arguments = args;
                objProc.Start();
                objProc.WaitForExit();
            }
            else
            {
                string caption = "Error in function LaunchProcess()";
                MessageBoxButtons buttons = MessageBoxButtons.OK;
                MessageBoxIcon icons = MessageBoxIcon.Exclamation;
                MessageBox.Show("Cannot find the following file: " + setupfile, caption, buttons, icons);
            }
        }

[Apoorv_Jain]

Bottom line is to have a bootstrap program that does all the things and you can write the bootstrap program in any language (be it a exe, a script, flash animation,a batch file, etc.).
All you need is an application or startup mode that contains the set of logical blocks to perform checks and invokes the correct msi.
A basic C code for a console application using printf and scanf can also be written to do all this along with functions checking in background for presence of dotnet, 32-bit vs 64-bit etc etc.

[BrHartmann]

Just to close off this discussion in case anyone is interested, I found another thread where Tobias79 described a simple way to use a pure installscript bootstrapper (http://community.flexerasoftware.com/showthread.php?t=193574&page=2), and this worked well for our needs.