In Part 2 of this article, we will talk about using the LaunchApp set of InstallScript functions to run an application. But before I begin, Part 1 can be found here:
Most people will opt to use the LaunchApp functions to run an application from within an installation. Whether the application is actually an application or a secondary installation program. Using these functions can get you into trouble sometimes. Okay. They can make you go crazy when things don’t go as expected.
Here are the functions, their number of parameters, and the order I would use them:
- LaunchAppAndWait – 3 parameters
- LaunchApplication – 6 parameters
- LaunchApp – 2 parameters
Let’s look at each of these.
We’ll begin with LaunchAppAndWait. It takes 3 parameters and here is an excerpt from the Help topic on the function.
In my installations, I use LaunchAppAndWait the most of all three functions. The reason is it only requires 3 parameters, and I can tell the installation to wait until the command finishes. For most tasks, this will do just fine. However, there will be times when you need more control. That brings us to the next function.
LaunchApplication takes 6 parameters, so it’s a bit more work to set up. Here is an excerpt from the Help on the function.
I recently was on a client project where I was having problems with LaunchAppAndWait. After some research, I changed to this function. I will discuss this problem later in the article.
LaunchApp takes 2 parameters, one less parameter than LaunchAppAndWait. The reason is it calls LaunchAppAndWait with LAAW_OPTION_NOWAIT as the third parameter.
Here is an excerpt from the Help topic on the function.
In most of the installations I have done where I’ve called LaunchAppAndWait, I have used LAAW_OPTION_WAIT as the third parameter. Because I want the installer to wait until the command finishes. That’s why I never use the LaunchApp function. However, you might like it.
Using LaunchApp Functions in a Basic MSI Installation
In a Basic MSI installation, when you call one of the LaunchApp functions, you will generally do it from an InstallScript custom action. The problem is where do you stick it in the sequence?
You can’t place the custom action in the Execute sequence, because the Windows Installer only allows one Execute sequence to be run at a time. That leaves the User Interface sequence. But where do you put it?
In my testing, I have found one place. Here is a screenshot of the Custom Actions and Sequences view of a Basic MSI project. Notice where I placed the InstallScript custom action.
The custom action is called RunApplication1 and I have placed it in a safe place at the end of the UI sequence after ExecuteAction. Place it in other places at your own risk. Remember most installation developers are tetering on the edge of sanity. Put this in the wrong place and you could go over the edge.
Using LaunchApp Functions in an InstallScript MSI or InstallScript Installation
When you are working in a script-based installation, all you do is drop one of the LaunchApp functions in the script. Just put it whereever you want.
Here’s an example of a scripted call to LaunchAppAndWait.
The call is straightforward, so I don’t need to explain it.
Problem and Solution
I recently worked on an InstallScript MSI installation adding some new enhancements. The installation was not new. It had been worked on over a 15 year period and was in very good shape. The client just needed some more work done and couldn’t afford to put any of their staff on it.
There were lots of Features and Components in the installation. More importantly, there were lots of Feature Events. If you click on a Feature in the Setup Design or Features view, you will notice that there is a section in the property sheet entitled Feature Events. So, what are they?
Feature Events only exist in script-based installations. Feature Events handlers carry out processes required just before and just after the installation or uninstallation of a single Feature. In the installer I was working on, there were several websites and application pools in the IIS view, and also several features that installed files to different virtual folders under C:\inetpub\wwwroot. The majority of the Feature Event handlers for these Features called LaunchAppAndWait, and the application they ran was appcmd.exe.
Appcmd.exe is an IIS configuration utility. You can use it to configure websites and perform many other IIS-related tasks. Now, we get into a problem I experienced.
When I was handed the project, it was an InstallShield 2010 project and needed to be upgraded to InstallShield 2011. I opened the project in IS 2011, rebuilt, ran it, and many of the websites were not showing up in IIS. After much research, the culprit was found to be the LaunchAppAndWait calls to appcmd.exe in the Feature Events. They worked in IS 2010, but stopped working in IS 2011. Of course, I immediately thought it was InstallShield’s fault. Right? After all, developers never make mistakes.
Here’s an interesting point about the LaunchApp functions. The return code can have one of two values:
ISERR_SUCCESS – indicates the application was launched successfully.
< ISERR_SUCCESS – indicates the application was not launched successfully.
The most important thing to remember when you are using the LaunchApp functions is this:
It is not the return code from the application you are executing!
Burn that into your memory.
The calls to appcmd.exe were failing, even though LaunchAppAndWait was returning success. After doing a bunch of research, I learned that when an application called from one of the LaunchApp functions fails, it generally fails due to insufficient privileges.
The answer was in changing the calls from LaunchAppAndWait to LaunchApplication.
With LaunchApplication, I had more control and could specify LAAW_OPTION_USE_SHELLEXECUTE as one of the options. When you use this option, LaunchApplication will call ShellExecuteEx instead of calling CreateProcess, like it normally does.
Here’s a code snippet with the change I made to one of the calls.
I hoped you have learned a lot from this topic. My experience with these functions has generally been pleasant with an occasional side trip into Hell. Remember what I told you and you will save yourself some aggravation.