John_E
Level 4

Understanding Key files

My question is about a legacy product (InstallShield Developer 😎 but since nobody seems to answer questions in that forum I thought I'd try asking here. It's probably still relevant in current InstallShield products.

I've noticed that setting a key file for a component prevents that component from being installed if the file is already present on the user's system. But no account seems to be taken of whether the user's file is older than the one I'm trying to install. An undesirable consequence of this is that a newer version of my setup.exe product fails to upgrade an earlier version installed on the user's system. What's the answer to this? Do I simply not bother using key files? Or is there some way of telling InstallShield to overwrite the component if its key file is present, but out of date?
Labels (1)
0 Kudos
5 Replies
TsungH
Level 12

If you have not, you will want to read up on File Versioning Rules.
0 Kudos
John_E
Level 4

Many thanks for the link. It helped me to understand an issue which has confused me ever since I first began using InstallShield. The only problem is that in practice, I can't seem to make it work. Here's my scenario....

The key file in question is an exe file. Like most Windows exe's it contains a VersionInfo section. The File Version and Product Version were initially both set to 1.2.8.0. This morning I updated both numbers to 1.2.8.1, rebuilt my app, rebuilt my setup.exe file and tried another upgrade. Unfortunately, I'm still getting left with the original copy on my hard drive, instead of the newer version.

Clearly, there's something I haven't understood properly. Am I updating the correct version numbers - or is there some other version number that I need to be modifying :confused:
0 Kudos
TsungH
Level 12

You will want to get a verbose installation log and see what actually happened during (major/minor upgrade?) installation. If you have a Basic MSI project, you can use the following command line. Use double quotes when there is space in the path.
msiexec.exe /i \your.msi /l*vx \your.log
0 Kudos
John_E
Level 4

Oops, I did something very silly 😮 (it's a bit early in the morning here - haven't quite woken up yet!)

I'd rebuilt the Debug version of my app but not the Release version. Now that I've built the correct version it all works as expected..!

The great thing about that link is that it explains why my non-versioned files have never updated properly with InstallShield. This has been a huge source of frustration for me in the 8 years that I've been an InstallShield user. It appears that if the target file's modification date is later than its creation date, MSI assumes that the user deliberately modified it and therefore, doesn't overwrite it.

So I took a look at some of the data files that I tend to install (these are often bitmaps, audio files, README.txt or whatever). In almost every case the modification date is a minute or two later than the creation date.

So THAT'S why they never got updated!!! At least I now understand why and can do something about it. Thanks for all your help.
0 Kudos
TsungH
Level 12

Haha... we all have done that.

Glad that you find the link helpful. 🙂
0 Kudos