InstallShield gives you many ways to provide additional functionality to an installation. Custom Actions are one way. Scripting is another way. While working on a recent client project, I found the need to use a Standard DLL, and it brought back familiar problems that I have had in the past. This arose from my use of UseDll(). Let’s talk about some common problems you can have with this InstallScript function.

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.