Enjoy!

Videos from “Creating MSI Installations with InstallShield 2010″

With virtual machines, you can set up different Windows operating systems and configure them according to your wishes. At a minimum, you need one virtual machine for each supported version of Windows that your product runs on. The virtual machines are saved on your hard drive and you can use them whenever you want.

Perhaps the biggest advantage is that you can run a virtual machine, test your installation, and then discard the changes when you’re done. So, each time you boot up the virtual machine, it is still in its “clean machine” state.

To get started using virtual machines, you can use Microsoft Virtual PC. I have used this for five years and have found it to be really nice. Plus it’s free. You can download it from the Microsoft website.

VMWare Workstation is also available, but it costs $100 to $200. I have never used it before, but a lot of people say it’s the best virtualization platform out there.

Regardless of which one you choose, make sure you use virtual machines in your testing.

Check it out: Creating MSI Installations with InstallShield 2010

To watch example videos from the course, go here: InstallShield 2010 Basic MSI Videos

Generally, I write the steps down in a Microsoft Word document. Sometimes, the info I write down is in the form of strings that have trailing and ending double quote marks. I run down the list of steps, and when I come to the string with the double quotes, I select and copy it from the Word document, and paste it into the InstallShield IDE. Big mistake.

For some reason, the double quote marks that are created within Word are not the same double quote marks that are created when you enter them manually into a field in the InstallShield IDE. So, when you paste the string into the IDE, it doesn’t work.

Sometimes, InstallShield will complain during the build. Sometimes it won’t, and your installation simply won’t work properly, leaving you wondering what is going on. You’ve entered everything correctly and it should work. But, it doesn’t.

Next time, manually enter those double quote marks into the InstallShield IDE. You’ll save yourself a lot of trouble and aggravation.

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.

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

endcatch;

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”

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.

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.