Often in installation projects, you will need a prerequisite that is not supplied by InstallShield in the Redistributables view of the IDE. In this case, you will have to create your own prerequisite. Here is the general procedure.
To use prerequisites, your installation needs to include Setup.exe. Setup.exe is considered to be a bootstrap application. When you run Setup.exe, the following things happen:
- Compressed files in the installation are extracted to a temporary folder.
- If prerequisites are set up to be installed before the main installation, their installations will be executed one at a time, in the order that the installation developer has specified.
- Each condition in a prerequisite will then be evaluated to see if the prerquisite is already installed on the machine. If it is not, or if it is, but the installed version is earlier than the version to be installed, the prerequisite will be installed on the user’s machine.
- The prerequisite installation will be executed silently. Usually the installation program is a setp.exe or an .msi file and there will often be several other files that are included with it.
- After all the prerequisites have been installed, setup.exe will then extract the .msi file and execute it. The .msi file is where the main installation takes place.
- The user interface is then displayed and the user will have to enter any required information in the dialogs.
- The installation then installs the application on the user’s machine.
Finding the files to include in a custom prerequisite can be relatively easy or take considerable time to track down. Even finding the correct files on Microsoft’s website can take time.
The big issue with custom prerequisites is the conditions that you have to create. If you get lazy and don’t create conditions, then your prerequisite installation will run every time your installation runs. That’s not good.
But, I know you are a responsible developer and are going to create conditions for your custom prerequisites. In the best case scenario, the files installed and/or registry entries created for a prerequisite are documented somewhere on the web. If the information is reliable, then you can just create conditions that look for certain items.
This screenshot shows the types of conditions that can be created for a prerequisite.
Condition Types for a Prerequisite
There are basically three types of conditions:
- Those that check registry entries.
- Those that check files.
- Those that check the platform setup.exe is running on.
Let’s look at each of these types.
To create a registry condition, you need to look on a machine where the prerequisite is already installed. Run regedit.exe, and look through the registry until you find an entry that corresponds to the prerequisite. This is sometimes easier said than done.
The first place you should look is HKLM/SOFTWARE. Company names are usually listed first, then in the underlying nodes, software packages are listed. Take a look at the following screenshot.
HKLM/SOFTWARE registry entries
Under SOFTWARE, there is Adobe, Adobe Acrobat, then a 10.0 node. I have found that you can do a registry check for the 10.0 node, and that will be sufficient for seeing if Adobe Acrobat Reader 10.0 is installed.
Adobe Reader is an easy one. But what if you can’t find a registry entry under HKLM\SOFTWARE? In that case, you will have to search the registry for the name of the software package. Sometimes that will find a unique entry that you can use for an existence check. But sometimes, you can’t find anything. You will then have to check for the existence of a file.
To check for an installed prerequisite file, you can first look under %ProgramFiles% for an .exe or .dll. However, it’s not always that easy. Like with the registry, you will sometimes have to search the entire C: drive to find a file.
The final type of condition you can create is for a platform. The easiest way to show this is with a screenshot.
Examples of platform conditions
This is the Conditions tab for the .NET Framework 3.5 SP1 prerequisite. You can see there is one registry condition and the rest are platform conditions.
When you create a platform condition, you will need to create a separate condition for each Windows version that the prerequisite can be installed on. Your condition may also need to include the bit-ness. In this example, the condition just checks for a Windows version with the bit-ness specified as Any. You will also find some plaform entries that are specific to 32-bit and 64-bit versions.
In the end, there is no magic to creating conditions for custom prerequisites. Sometimes it’s easy. Other times it’s a nightmare. For example, I have spent a lot of time trying to create a condition for a custom prerequisite that installs Visual Basic Powerpacks 10.0. Some posts I’ve read have said to check for Microsoft.VisualBasic.PowerPacks.Vs.dll. However, you can’t always find that file on the hard drive, even though Programs and Features shows the package as being installed. So for now, I have not been able to create a condition for that package that is reliable on different versions of Windows.
In the end, you will have to create conditions for any prerequisites you create. Don’t be lazy and leave the conditions off. Remember, when you do that, the prerequisite will be installed every time your installation is run. That is incredibly annoying.