I have noticed that some people are confused by the differences between Advanced UI and Suite/Advanced UI projects. I feel the people at InstallShield should have chosen slightly different names for these projects. I would have called them Suite projects rather than Suite/Advanced UI projects.
Which of these project types you can use depends on the edition of InstallShield you have. I have some videos that illustrate the differences between these two project types. Watch them here:
If you have a script-based installation, InstallScript or InstallScript MSI, the image format you choose for your installation splash screen is important.
Splash screens can be added to the Splash Screen section of the Support Files view. In that section is a Language Independent folder and a folder for each language your installation supports.
The Splash Screen section of the Support Files View
In the above screenshot, you see that I have opened an InstallScript MSI project to the Support Files view. In this project I have added a .bmp splash screen to the Language Independent folder. Also, my installation only supports English, which is why I just made one version of the splash screen. Since my splash screen is in English, I could have put it in the English folder, but I chose to put it in the Language Independent folder.
Here’s the important part. If you are using a pure InstallScript project, you can use .bmp or .gif files as splash screens. If you are using an InstallScript MSI project, you can only use .bmp files as splash screens.
What about Basic MSI projects? For those, you should use a .bmp splash screen.
An often overlooked aspect of creating scripts for custom dialogs is to disregard the reading and writing of data to set up a silent install.
For example, when you run an installation in normal mode, the user interacts with dialogs and enters information such as the installation directory. That information is then used during the installation. During a silent installation, this data has to also be supplied.
For silent installations in script-based projects, you need to create a response file. This is done by running the installation in normal mode with the -r option. You enter data into the dialogs and that data is written to an .iss file. Later when the customer, system administrator or other user runs the installation in silent mode, the .iss file will be used to provide the data in place of a user doing it.
In a custom dialog script, you have to check if the installation is being run silently at the beginning of the script. You have to also check if you are in record mode at the end of the script. These actions are accomplished by using the SilentReadData and SilentWriteData functions.
The following is a screenshot of a custom dialog script. The custom dialog was created by taking the existing CustomerInformation dialog and adding an email field to it.
Custom dialog script for a modified CustomerInformation dialog
The custom dialog has three fields, a Name field, a Company field and an Email field. In the SILENTMODE section at the beginning of the script, these fields are read from the .iss file when the installation is run in silent mode.
In the RECORDMODE section at the end of the script, the values are written to an .iss file when the installation is run with the -r option. This is how the .iss file is created.
Setting up these two sections in a custom dialog script will allow your installations to work properly during a silent installation. If do not do this, the silent install will not work as expected.
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.
Often when you are working out a SQL Server prerequisite installation in your InstallShield project, it will fail a few times before you get it right. Generally, SQL Server will install for a little while and then fail at some point. The question on your mind is always how to find the problem.
You are probably familiar with looking at installation logs and I have written at least one post on the subject. But did you know that when you install SQL Server, an installation log is always produced? It’s just not in the %TEMP% folder. This is true even when your installation fails.
To look at the installation log, go here:
Looking at this log will always help you find the problem.