Newcomers to InstallShield and the Windows Installer always get tripped up by one thing – Version Numbers. So, let’s take a close look at how version numbers are handled.
The Windows Installer uses a three-part version number. As a result, all version numbers must conform to the following format:
major.minor.build
An example version using this format would be 2.10.015.
That’s nice you say, “But all the version numbers in my company are of the format, 4.50.100.451.”
Okay, but the Windows Installer will ignore the last part (the .451). Now, you can use a four part version number in Basic MSI and InstallScript MSI projects in InstallShield, but the Windows Installer will still ignore the fourth part.
I can’t explain why Microsoft came up with this format. At least 80% of the people I talk to use a four-part version number in their company. And they are all just as upset about this as you are. So, to get you over being upset, here’s a little humor.
The Windows Installer has it’s own internal version number that signifies what version it is, and I bet you can’t guess what the format is:
major.minor.build.update
We see that Microsoft wanted the internal version number of the Windows Installer to have four parts, but the public can only use version numbers with three parts.
Makes perfect sense to me.
Recently, I had to do an installation in Swedish for a client. I own InstallShield Professional, so I wondered how to pull it off. I ended up doing something really easy which worked very well.
I downloaded the trial version of InstallShield Premier, installed it, and exported the Swedish string table. I then went back to my copy of InstallShield Professional and imported the Swedish string table before I did any work on the installer. After importing, I did all the work the client required.
In this installer, I didn’t create any English strings, so my theory was that when I gave the finished installation to the client, all he would have to do was rebuild the project on his end, and everything would be fine. Well, that’s exactly what happened.
The only caveat in doing this technique is that if you create any English strings or any English custom dialogs, then the client will have to translate those strings from his location. In my installation, I didn’t have to do any of those things, so it made it easy for the client.
Now, what was the difficulty in this whole project? The only difficulty was that all the dialogs were in Swedish, so I sometimes had to look back at the actual dialog name, to understand what was really going on. But it all worked out.
This technique will work for anyone needing to create an installation that is in a language different from the language of the InstallShield copy they own.
If you ever have a need to change the order of files copied to the target system in a Basic MSI project, you can edit the File table.
Go to the Direct Editor view in the InstallShield IDE and select the File table. Here is a screenshot of the file table from one of my own projects:
The FileName column holds the name of the files being copied to the target system. The Component column holds the name of the Component that each file belongs to. For this discussion, we are interested in the Sequence column.
Notice that InstallShield places 1s in this column by default. But if you have a file that you want copied to the target system first, just leave that with a Sequence of 1, and change everything else to a greater number. Files are copied to the target system with the lowest sequence numbers first, highest sequence numbers last. In our example, let’s say we want Mega View.exe copied first, so we leave that as a 1. All other files should be changed to something greater. Here we are using 10.
Now, what’s the downside to this strategy? It’s that everytime you add new files to your project, you will have to go to the File table and set the Sequence for those files.
I entertained doing this for a client project, so I thought I would pass it on.
A very common point of confusion is where a person wants to create an installation in InstallShield that uses the Windows Installer. But they don’t know which project type to use. Basic MSI or InstallScript MSI.
The overwhelming majority of people prefer to use the Basic MSI project. But if you are new to installation development, you may find that the Basic MSI project has a steeper learning curve. I have written posts on this. Just search this website.
When Microsoft created the Windows Installer, they realized it would not provide all the functionality to cover every conceivable Windows installation scenario that people would come up with. The possibilities are just too endless. However, even writing custom actions in a Basic MSI project will not always accomplish what you want. So, why would you ever want to use the InstallScript MSI project?
You should know that to some installation developers, the InstallScript MSI project type is a joke. These people can not fathom why you would use such a thing. Especially, when it is seen as a hybrid of the Basic MSI and InstallScript project types. However, the InstallScript MSI project uses the Windows Installer, the InstallScript project does not.
Other developers feel the InstallScript MSI project is the weakest type of project that InstallShield offers. However, there are some very appropriate times to use it.
If your boss or client is requesting something out of the ordinary, it may not be possible to accomplish it in a Basic MSI project. Generally, this has to do when they want control over every aspect of the installation. I’ll give you a perfect example.
Let’s say your boss wants a user to be able to click the Uninstall button in the Add/Remove Programs dialog and then bring up a Custom dialog box which presents two options. Uninstall option 1 and uninstall option 2. Let’s say option 1 drops a SQL Server database and option 2 does not. The user chooses an option, clicks the Next button, it goes to the ReadyToRemove dialog, the user clicks Remove, and the program is uninstalled according to the option they selected.
Now, you can not do this in a Basic MSI project. Why? Because when you click the Uninstall button in Add/Remove Programs, the User Interface sequence is skipped, and just the Execute sequence is performed. So, you can’t do it in Basic MSI. If you want this degree of customization, then you should consider the InstallScript MSI project.
There are other examples where an InstallScript MSI project makes more sense, and it’s generally when you want a higher level of customization than Basic MSI is able to provide. And that’s when it’s perfectly acceptable to use InstallScript MSI.
Don’t let anyone make you feel bad for using it.
I’m currently doing a very common task. I’m creating a Basic MSI installation where I have to edit several prerequisites and then get everything to still work. However, it’s not working as planned. During the installation of one of the prerequisites, it’s failing with an ambiguous message.
Here’s the message:
“The installation of Microsoft SQL Server 2008 Express SP1 (x86) appears to have failed. Do you want to continue the installation?”
Here is a screencap of the error:
So, what do you do? Well, after a day’s worth of investigation I found out that the error was caused by the wrong combination of command line options on the Application to Run tab of the Prerequisite Editor. When I corrected the options, the problem went away
I’m not going to give you specific options because the combinations are endless. In addition, the main point I want to make is that this can not just happen with SQL Server 2008 Express, it can happen with any prerequisite you have edited.
One test you can do is create a batch file with the name of the executable and the corresponding command line options. If you get it working from the command line, then you can use those same options in the Prerequisite.
Try this the next time you run into trouble.
