Get Handle to the MSI Database in An InstallScript MSI Project

If you are working in an InstallScript MSI project, you will sometimes need to call a Windows Installer function. To do this, you will need a handle to the currently-running MSI database.

In a Basic MSI project, you have access to this handle from any InstallScript custom action. This is because hMSI is always one of the parameters passed to InstallScript functions in custom actions.

In InstallScript MSI projects, you have to use something different. Have a look at this code snippet:

The handle to the MSI database


ISMSI_HANDLE is the system variable you should use to access the currently-running MSI database.

 

How to Get the Actual Return Code From the LaunchApp Functions

When you use one of the LaunchApp functions (LaunchApp, LaunchAppAndWait, LaunchApplication), you get a return code. However, that return code only shows the result of InstallShield executing the command.

If InstallShield was successful, you will get a return code indicating success, which is ISERR_SUCCESS. If it was not successful, you will get a value less than ISERR_SUCCESS.

Here is a code snippet showing you how to get the actual return code from the command being executed:
How to Get the Actual Return Code From a LaunchApp Function

See how easy that was.

 

Using the Summary Information Table in the Direct Editor

One of the tables in the Direct Editor view of the InstallShield IDE is the Summary Information table. The information stored in this table can be useful to you at different times. I’ll give you an example of one such use.

First off, here is a screenshot of the Summary Information table for an installation that is being built by InstallShield:

The Summary Information table in an InstallShield-built installation

The Summary Information table in an InstallShield-built installation


Notice that the Creating Application field shows InstallShield 2012 – Premier Edition 18.


Now, let’s take a look at the Summary Information table for an installation that was built with another tool:

The Summary Information table in a Windows Installer-built installation

The Summary Information table in a Windows Installer-built installation


Notice that the Creating Application for this installation was the Windows Installer. This information was built by a Microsoft tool. Perhaps Orca. Perhaps the Setup Toolkit that used to be included with Visual Studio.

Here’s one of my own uses of this information.

I had a recent client who had purchased the rights to an application and associated installation. He was given several hard drives worth of information. I was hired to work on the installation and re-brand it for his company.

The installation was an InstallScript MSI project that at the end of the installation was running two separate .msi files. I needed to find the installation projects that created these .msi files so I could incorporate everything into one installation project, instead of three.

I opened each .msi file in InstallShield and went to the Summary Information table in the Direct Editor. There I learned that InstallShield hadn’t built the .msi files. Something else had. That was useful information to know. It told me there weren’t going to be any InstallShield projects that I could look at. We had to look elsewhere.

Just remember the Summary Information table is there. You may need to look at it sometime.

 

Prebuild and Postbuild Events in An InstallShield Installation

InstallShield allows you to specify commands that can be run at various stages of the build process. These commands are called Build Events. This can be very useful, but in order to use this functionality, you must have the InstallShield Premier edition.

To define a Build Event, just go to the Releases view, click on a release, then click the Events tab. There you can define Prebuild, Precompressor and Postbuild events.

When you enter a command in an event, you can use any of the path variables and environment variables that are defined in your project.

Here are the variables you can use for event commands:

  • ISReleaseName – name of the release that InstallShield is building.
  • ISProductConfigName – name of the product configuration that contains the release that InstallShield is building.
  • ISReleasePath – the build location of the release that InstallShield is building. It is set through the Release Location setting on the Build tab for a release in the Releases view.
  • ISReleaseUsesShallowFolderPaths – set to true or false to indicate whether InstallShield uses a shallow folder directory structure when building your release.

For an example of a Prebuild event, have a look at the screenshot below.


The Events tab for a release showing a Prebuild event

The Events tab for a release showing a Prebuild event



Here, I have selected the Events tab for the CD release. For the Prebuild event, I am running two commands that copy a couple of SQL database files from one folder to another.

 

How to Determine What Kind of InstallShield Project You Have

I have noticed that a common scenario among new users of InstallShield is that they do not know what kind of project they have.

It generally goes like this. A person is an application developer in a company and their boss gives them an existing InstallShield installation project that was done by someone else. It is now their job to add new functionality to the installation. The problem is they don’t even know what kind of project they have.

The easiest way to determine this is to open the project in the IDE and look at the title bar. The project type will be shown in square brackets.

The project type is shown in square brackets on the title bar

The project type is shown in square brackets on the title bar