You run an installation on a test machine and get a message asking if you want to upgrade an earlier version of a product. Puzzled, you look on the machine and sure enough, there is an earlier version of a product installed. However, your intent was not to create an upgrade installation. You are creating a new installation for a new version of a product. So, why is this happening?
There seem to be two major types of upgrade situations out there. The first type is where a company truly wants their existing products to be upgraded to their newest product. In this case, an upgrade or patch installation is created.
The second type is where a company, for whatever reason, does not create upgrade installations for new versions of their products. When each new version comes out, they require users to uninstall any older versions first, then install the new version of their product. There could be many reasons why they do this. Sometimes, they just don’t have the installation experience in-house to create an upgrade installation. So, they require users to uninstall older versions before installing new ones.
If you are in the second type of upgrade scenario, and your intent was not to create an upgrade installation, then you may go nuts trying to figure out why it is happening. “Why, oh why, does InstallShield think I am doing an upgrade when I don’t want to do one?”
About this time you start to think that life is not fair, and if you can just make it through this situation, you’ll promise to be a better person in the future. But only IF you make it through this situation.
In the first upgrade scenario, you should consult the InstallShield Help and learn what Windows Installer codes you need to change for the upgrade you are creating.
In this second upgrade scenario, you should consult the InstallShield Help and learn the ramifications of changing Windows Installer codes when creating upgrades. I know you don’t think you are doing an upgrade installation, but you are going to have to look at this sometime. So, do it now.
If you are in the second type of situation, ask yourself if you did the following:
- You copied the previous installation project, let’s say for the 2009 version, and just changed the date in the strings to show 2010. However, you did not change the Product Version, the Product Code, the Upgrade Code, or the Package Code. InstallShield sees that one or more of the codes are the same, and it thinks you are doing an upgrade. This is not InstallShield’s fault. When you create an upgrade, you have to follow the rules for the specific type of upgrade you are doing, and change the Windows Installer codes (GUIDs) accordingly.
In consulting, I see this a lot. I’ve gotten several calls where a company is trying to create an installation for the new version of their product, and when they test the installer, InstallShield thinks it’s doing an upgrade. Often this is because the installation was created by one person who is no longer with the company, and a second, third, or fourth person is now working on the same installation project, trying to get it working for the new product. Installation projects have a way of getting passed around from person to person in a company. Nobody wants to be stuck doing them.
If the Windows Installer codes are not the culprit of your problem, another possibility is the ISPreventDowngrade custom action. Go to the Upgrades view and expand the Upgrade Windows Installer Setup node. This custom action is placed there by InstallShield in Basic MSI and InstallScript MSI projects.
ISPreventDowngrade prevents a person from installing an earlier version of a product over a later version of the same product. One cure would be to delete this custom action. You’d be surprised that a lot of problems go away when you do this. However, ISPreventDowngrade is there for a reason, so I don’t recommend deleting it unless you really know what you are doing.
Another possibility in the Upgrades view is that the original creator of the installation may have tried to do an upgrade, but couldn’t figure it out, so they just gave up. The result being that a half-configured upgrade is still in the Upgrades view. If so, that could be the cause of your problem.
Next time you have this type of problem, check the Windows Installer codes, and the Upgrades view. Between these two areas, you will probably find the culprit of your problem.
If you are new to InstallShield or the InstallScript language, and are coming from the C# or VB.NET world, you may be wondering how to handle exceptions in your installation.
The InstallScript language has a Try – Catch capability just like the languages you are used to working in. Here’s what it looks like:
try
// do some stuff
catch
// handle the exception
endcatch;
There are several types of log files generated in an InstallShield installation. Most people are not familiar with all of them. This post will fix that.
The four types of log files are:
- Build log
- Installation log
- Uninstallation log
- Bootstrapper log
Build Logs
A build log is automatically generated when you build a release. InstallShield creates this file and it contains all the steps performed during the build process. It also lists any errors. The build logs can be found in the Release’s LogFiles folder.
Installation Logs
To create a log that shows the steps occurring during an installation, we have to go the registry. Now remember, this is for Windows systems earlier than Vista. You simply set the value of the registry key to voicewarmupx to have all of the installation steps logged in the file.
Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Reg_SZ: Logging
Value: voicewarmupx
If you aren’t clear on this, you go to the above registry key, look for the Logging entry, if it isn’t there, you must create it. It is a string entry. Then set the value to voicewarmupx.
On XP, it will be located here:
C:\Documents and Settings\UserName\Local Settings\Temp
Look at the log file (it has a .log extension) with the latest date.
On any Windows system, you can enter %temp% in the Run box or Start Search box, and you will get the location of the log file.
Now, if you are on Windows Vista, you can just go to:
Installation Information
General Information
Product Properties
Create MSI Logs
Yes
This setting only applies to Windows Vista and higher and will be ignored on all other Windows systems. On those systems, you will need to use the first method to perform in-depth logging of your installations.
Uninstallation Logs
The registry entry we just set will also trigger uninstallation logs to be built. Just look in the Temp folder after you have uninstalled your product, and find the latest log file.
Bootstrapper Logs
InstallShield has a method for creating a log file for the Setup.exe and Update.exe bootstrappers. You can simply use the /debuglog parameter from the command line when you run Setup.exe. This command line parameter can be used with the Setup launcher for Basic MSI, InstallScript MSI, and Web projects.
Here it is:
Setup.exe /debuglog
You will notice that a file called InstallShield.log has been created in the same folder as Setup.exe.
What you must remember here is that, this is only the log file for the Setup.exe bootstrapper. At least that is what it seems. When you look at this log file, you see that it doesn’t contain the detailed information available when compared to the log file created as a result of placing the value in the registry, which was outlined in the previous movie.
There is one more thing to know about the /debuglog command line parameter. You can also specify the full path to the log file, so it could be created in an entirely different location from Setup.exe. This is useful if Setup.exe is on a CD-ROM, or any other unwrittable location. Here is an example of that:
Setup.exe /debuglog”C:\SetupLogFile.txt”
I have to talk to you about my health. I have an unsettling form of amnesia that develops whenever I am faced with an installation development problem. It comes on suddenly, often with no notice whatsoever. I’m talking about something so basic, yet at the same time, so very unsettling. I forget to check the log files.
Don’t laugh. I know I should check the log files first, but it’s generally the last thing I think of doing. Don’t make the same mistake.
The log files should be one of the first things you check.
At times in an InstallScript or InstallScript MSI project, you want to be sure everything is removed on an Uninstall, and I mean everything. Every last drop of stuff you’ve installed on the user’s computer.
To remove features during an Uninstallation, you have several choices:
- FeatureRemoveAll() – forces the removal of all features that were installed previously.
- FeatureRemoveAllInLogOnly() – forces the removal of all features that are not in the current media, but were installed previously, as recorded in the setup log file.
- FeatureRemoveAllInMedia() – forces the removal of all features that are in the current media and were installed previously.
- FeatureRemoveAllInMediaAndLog() – forces the removal of all features that were installed previously, both those that are in the current media, and those that are not in the current media but are recorded in the setup log file.
When you want to remove everything, the best bet is to use FeatureRemoveAllInMediaAndLog().
Now, does this mean you can just rely on the function and not test thoroughly? No. You still have to test the uninstallation thoroughly. Things happen. You may have missed something. It happens to all of us and is nothing to be ashamed about. Testing is the final word.
What about when you are given an existing installation you didn’t create, you’re told the uninstallation doesn’t work properly, and told you have to fix it? In that situation you have to be a detective and go through the project and find the mistakes. It can take a while and can be very frustrating, but that’s the only way to solve the problem. Okay, you could start over, but that is not always an option. Especially on huge installations that would take a very long time to recreate.
I’m going to go out on a limb here and say that you should never have any problems with an uninstall. That is IF you have set up your InstallShield project correctly. That’s been my experience.
