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:

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

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:

See how easy that was.

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

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:

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.

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.

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.

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.

In a Basic MSI project, the main way to provide additional functionality is through custom actions. Here are different custom action types that can be used with DLLs:

• Standard DLL – custom action calls a standard Windows DLL and places the result in a property.
• Managed Code – custom action calls a method in a managed code class library and places the result in a property.
• InstallScript – custom action based on a script that can call a DLL through UseDLL and UnUseDLL.

In InstallScript and InstallScript MSI projects, you just make calls to DLLs or class libraries from your script.

In order to call a method/function in a DLL, you have to first load the DLL. You do that with a call to UseDLL(). Next, you call the method in the DLL. Finally, you unload the DLL from memory with a call to UnUseDLL().

Here is a screenshot of typical script that uses a DLL called Utility.dll.

The code is very straightforward. I want to call a method in a Standard DLL named utility.dll. I have added utility.dll to the Support Files view, so in the script, I first make a call to MsiGetProperty() (my version has Ws in front of the name) to get SUPPORTDIR. Then, I build the path to the DLL. Next, I load the DLL into memory. Next, I call the method in the DLL. Finally, I unload the DLL from memory.

Generally, if you have a problem, it will be in the call to UseDLL(). In other words, the call will fail, and the DLL won’t be loaded into memory.

There are two common reasons that UseDLL() will fail:

1. The path you pass to UseDLL is incorrect. This could be because the path is not what you think. Or the path could be correct, but the DLL you are loading is not there.
2. The DLL you are loading has a dependency which is not present on the target system.

Here’s a another version of the above script. This time, we are loading a dependency of our DLL, which is msvcr100.dll.

Notice the script builds the path to the DLLs. It then changes the current directory to be that directory (something the Help topic for UseDLL suggests). It then loads msvcr100.dll. Then it loads our DLL, utility.dll. It then calls the method and sets a property equal to the return code. Finally, it unloads utility.dll and msvcr100.dll from memory.

If you have problems loading your own DLLs into memory and using them, you will now know a couple of things you can look for.

Recently I was working on a client project that was an InstallScript MSI installation. I had walked through the source code and had many several successful debug sessions until one tripped me up. I went to the toolbar, clicked the Debug button, and received an exception. The dialog box that showed the exception had a link I could click. When I did that, it created an email to send to InstallShield outlining the exception.

Here is a screenshot of that exception:

Unfortunately, this information did not give me a clue to what was happening.

No matter what I did, I couldn’t get rid of the exception. At one time, I thought my installation of InstallShield 2012 was corrupted, so I did a Repair installation. That didn’t help.

Next, I rebooted the machine and tried to debug again. That didn’t help either.

After several other failed attempts to resolve the problem, I decided to look in the registry. It was there that I found the problem.

Earlier, I had installed the client’s previous installation and then uninstalled it. I found that during the uninstall, it left a lot of trash on the computer and in the registry. By trash, I mean that the uninstall was not complete. A lot of stuff was left behind. After I cleaned up the trash, I was able to successfully debug my new project.

I am just passing this on in the hopes that it might help someone in the future.

You build your installation and test some aspect of it. You then go back to the InstallShield IDE and make a small change, then build it again. When you do, you get all kinds of errors that make no sense. Here is a screenshot of what I am talking about:

All I did was make a small change, then rebuilt, and I got all these errors. So what’s the solution?

The solution is to just build it again and the errors will generally go away.

I don’t know why this happens. Perhaps files are locked the first time you try to build. Then they aren’t locked when you build a second time, and it succeeds. Whatever the case, I’ve found just build again and the errors usually go away.

A Key File is used by the Windows Installer to detect the component’s presence on the target system and whether it needs to be updated.

In order to create advanced Component settings, you must specify a Key File.