Basic Introduction to InstallShield and Windows Installer
The scenario here is that the previous install developer won the lottery and ran off to Bimini with his girlfriend, leaving YOU the job of taking over a dozen different InstallShield 12 install projects. Let's assume you know very little about installer technology other than the fact that you've installed software a jillion times and watched that little progress bar for longer than you care to admit. Let's also assume you are fairly computer-savvy. You understand software and computers, in general, but you need not be a hard-core code writer. Ready? Action!
The Players
First issue... who's who? InstallShield? Acresso? Windows Installer? MSI? Who are all these people?
Windows Installer (WI) is the name of the technology (from Microsoft) that has become the new standard for installation and deployment.
MSI is a the default file extension for Windows Installer databases. People have gotten used to using "Windows Installer" and "MSI" pretty interchangeably.
InstallShield (IS) is the name of an installation software that's been around for years (before Microsoft Windows Installer ever existed). Before MSI's existed, InstallShield used a script-based technology (based on their own proprietary scripting language called InstallScript) to define installation and deployment packages. There's also a Wiki article on InstallShield, though it isn't much... http://en.wikipedia.org/wiki/InstallShield
Acresso is the name of the company that makes InstallShield (as of 2008). InstallShield used to be produced by a company called InstallShield. In 2004 the InstallShield product line (company?) was sold to MacroVision. I wasn't real excited about that and didn't find that it improved the product or service much. But hey.. that's my opinion. In 2008 the InstallShield product line was sold again to a company called Acresso. It remains to be seen if this helps or hinders the product and its quality and reputation.
The Technology
Nowadays it seems like the only smart thing to do is to use an MSI-based installer. It integrates so completely and consistently with the Windows operating system that it only makes sense to use it if you are installing on Windows. So... what is the overall concept for WI (Windows Installer)?
The key here is to realize that the installation instructions are essentially stored in a database, made up of tables with columns and rows. The The Wikipedia article on it gives a pretty good overview. Check it out... http://en.wikipedia.org/wiki/Windows_installer
When you run the program, you call the WI engine -- msiexec.exe. The engine then acts on the instructions found in a database (an MSI) -- myapp.msi.
The information in the various tables of the database tell WI what UI to display, what to do with the information the user enters into any dialogs, what files to install, what registry keys to create, any extra actions to take and what order to do this all in, etc.
There are several different applications that you can use to create an MSI. InstallShield is only one of them, but it does seem to be one of the most common ones. The benefit of using some sort of graphical IDE for creating MSI's is that it takes care of all the cross-table interactions for you. For example, if searching for a registry value actually requires entry in 3 different tables - you get to define your search in one window and InstallShield takes care of creating the entries in all 3 tables for you and you don't even have to know about it. This is great for a new user! I couldn't have started using WI without the InstallShield IDE.
As you become more familiar with the product, and as your needs become more complex, you will eventually get familiar with what is actually going on in the tables 'behind-the-scenes' when you design something in the InstallShield UI. At some point you will find that you need to do something that you can't actually do from one of the InstallShield wizards and you have to edit a table and it's rows directly. That's ok. InstallShield gives you a Direct Editor so you can do just that. No problem.
Three flavors to choose from
So what is the difference between a Basic MSI, an InstallScript MSI and an InstallScript installer? Simple...
An InstallScript installation is old-school. It doesn't use the Windows Installer engine at all. Instead you define the installation package's actions using the InstallScript scripting language. You will find that the end result quite similar. The major benefit in my mind is flexibility.
A Basic MSI package uses the built-in functionality of the Windows Installer, which is quite robust. You get the benefit of the InstallShield UI with which to create the MSI. You are, however, limited to the database structure and if you need to do something that exceeds the base functionality, now you have a choice (or a challenge?) in choosing a method to extend the MSI functionality. Options include vbscript, javascript, windows API dlls, write your own (C++) dll. The major benefit in my mind is reliability. If you are *only* using WI functionality then you know what what you are using has been well-tested and extensively exercised by a huge programmer and user base. The more you limit yourself to the basic WI functionality, the less opportunity for programmer error and the more reliable your installer is likely to be.
An InstallScript MSI is a half-breed. Essentially it is an MSI, with an added layer of execution on top driven by InstallScript. This allows the UI to be driven by the InstallScript engine, which then calls the MSI engine to make the actual changes to the system. Theoretically this should be the best of both worlds. You get the flexible and robust extensability available from InstallScript functions, but the reliability and safe structure of an MSI.
I use a Basic MSI wherever possible because I don't want the added layer of the InstallScript engine to create potential problems. But I'm also overly cautious ;-) I will probably start using InstallScript MSI's over the course of the next year because for security reasons (read: Vista) I need to move away from vbscript in my custom actions and InstallScript is a good alternative.