If you are working in an InstallScript or InstallScript MSI project, then you should remember to study what the default event handlers are doing.
Let’s say you have created a new project, and have done some work in a couple of the event handlers. All the other event handlers are not present in your script (InstallShield is calling them behind the scenes). If you are confused how a certain part of the installation is working (that you have not yet touched or changed), then you should add the appropriate event handler and check it out.
For example, if you have everything working properly during an initial installation, and you now need to work in the maintenance installation, you may wonder how to go about this. The first thing would be to go to the top of the InstallScript view and add the appropriate event handlers to the script (if they have not already been added to the script). In this case, you would want to add OnMaintUIBefore and OnMaintUIAfter.
After doing this, you can study what is there by default in these handlers and then better understand where to add your own code.
Another example is where you don’t have a new installation, but rather have one you inherited from someone else. You are not clear what calls were placed in the script by InstallShield, and what were placed by the previous installation developer. In this case, I would create a new project in a new folder, add the appropriate event handlers I want to study, then build the project, and step through in the debugger.
This should all sound perfectly logically, but I even forget to do this sometimes.
In closing, if you are not clear about the default behavior of any installation that has a script, add and/or examine the default event handlers. You will gain a lot of clarity and will even learn some things.
If you haven’t watched them yet, you should go to the following link and watch the example videos from the “Creating MSI Installations with InstallShield 2010″ course.
Enjoy!
Videos from “Creating MSI Installations with InstallShield 2010″
For the last five years I have been using virtual machines to test my installations. It is by far the best method. If you are not using virtual machines to test, you are missing out.
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.
I have just released a new training course on DVD, “Creating MSI Installations with InstallShield 2010″. In addition, I have posted some example videos from the course.
Check it out: Creating MSI Installations with InstallShield 2010
To watch example videos from the course, go here: InstallShield 2010 Basic MSI Videos
I am a big fan of writing down procedures. If I have a certain way I create a custom action, or a release, or anything else in InstallShield, I usually write it down. That way I don’t have to reinvent the wheel the next time I do it.
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.
