I can’t begin to tell you how many people want to launch another application from within an installation. I get emails from people asking how to do it. I get clients who want to do it. I even dream about doing it. I can’t even get a decent night’s sleep without thinking up new ways to do this cursed task.
Here’s a typical request I get:
Client: We want to call a second installation program from within our main installation, and have that second installation call a third application which will then call a fourth installation that in turn calls a fifth application.
Me: Aaaaaa, okay.
Client: Oh, I almost forgot. We need the fifth application to call a couple of other minor installation programs. You can do that, can’t you?
Me: You’re talking about five levels of nested applications!
Client: Right. That’s not a problem, is it?
Me: Oh, no. It’s done all the time.
Let’s talk about how to actually do this. We won’t talk about doing five levels of nested applications/installations, but rather just one level. Calling another application/installation from within a main installation. That’s enough work as it is.
Here is a list of the more common methods used to run an application:
- Chained MSIs
- Launch an Executable Custom Action
- Managed Code Custom Action
- LaunchApp, LaunchAppAndWait, or LaunchApplication
I would always choose to use a Prerequisite first, if at all possible. If one didn’t exist, I would create one. When the application to run is an MSI file, I might use a Chained MSI. If the application is an executable, I might use a Launch an Executable Custom Action. I could also choose to run the application from a Managed Code Custom Action. As a last resort, I would call one of the LaunchApp functions. The method I choose ultimately depends on what the application is and the options I have for running it.
In Part 1, I will briefly touch on Methods 1, 2, 3, and 4.. In Part 2, I will talk about Method 5. From my experience, that’s the one that gets most people into trouble.
If the application you want to run is another installation program, you could choose to run it by way of a Prerequisite. A Prerequisite is an installation for a product or technology framework that is required to be installed on the user’s system before your product is installed. That’s why it’s called a Prerequisite. Examples of Prerequisites are Windows Installer 4.5, .NET Framework 3.5 SP1, and SQL Server 2008 Express R2. Prerequisites are run before the main installation takes place.
Prerequisites can be added to any of the three main InstallShield project types, Basic MSI, InstallScript MSI, and InstallScript, just as long as your Release contains Setup.exe. The reason is because the Prerequisite is launched by Setup.exe before the main installation takes place. Setup.exe acts as a bootstrapper to launch the Prerequisite, and also elevates the Prerequisite process so that it is run with the proper privileges.
Prerequisites are found in the Redistributables view of the IDE. If you find that InstallShield doesn’t include a Prerequisite that you need, you can create your own. To do this, you use the Prerequisite Editor.
A Prerequisite can include multiple files, one of them being a Setup.exe or MSI file. Generally, the options for a Prerequisite will include one that runs the installation in quiet mode. That way the user won’t have to interact with the Prerequisite installation.
Prerequisite creation is a very worthwhile skill to learn, and there will be times when it will save your butt because no other option is available.
A final point about Prerequisites is that you could take the Prerequisite files and run them as a stand-alone installation.
Beginning with Windows Installer 4.5, support was provided for Chained MSIs. Obviously we’re talking about the Windows Installer here, so Chained MSIs will only be available in Basic MSI or InstallScript MSI projects.
Chained MSIs are multiple packages that are installed using transaction processing. When you use Chained MSIs, all of the packages are installed in a single transaction, thereby bypassing the Windows Installer limitation that permits only one Execute sequence to be run at a time.
You set up a Chained MSI in the Releases view of the IDE.
In this screenshot, you see there is a CD-ROM release and two Chained MSI applications. When the release is run, the main installation is run along with the installations for the two Chained MSI packages.
When would you not be able to use a Chained MSI? That would be when your secondary installation is a Setup.exe file, and not an MSI file.
Launch an Executable Custom Action
If you are using a Windows Installer type of installation, either Basic MSI or InstallScript MSI, you could choose to run your application with the Launch an Executable Custom Action. However realistically, you would probably only do this with a Basic MSI installation. In an InstallScript MSI installation, I would just call one of the LaunchApp functions from the script.
Here is a screenshot showing the selection for creating the New EXE Custom Action.
With this type of Custom Action, you can specify the Executable file, the Command Line, in addition to the usual Custom Action parameters.
Managed Code Custom Action
If you are using a Windows Installer type of installation, you could choose to use a Managed Code Custom Action.
Here is a screenshot showing the New Managed Code type of Custom Action.
When you create the Custom Action, you will be asked to specify the DLL/Class Library, the parameters and the return value. Do not enter the parameters and return value manually! Rather, select them from the drop-down lists. I have found that entering them manually can often cause problems.
You can write your class library in the language of your choice. I always use C#, but that’s just my preference.
The managed code routine will need to call an appropriate .NET function to run your application. I have written lots of Managed Code Custom Actions, but not any that have run an application. However, I’m sure you won’t have any trouble looking up an appropriate function in the Help.
Part 2 Coming Up!
In Part 2 of this article, I will talk about using the LaunchApp, LaunchAppAndWait, and LaunchApplication functions.