|
In my many years of work with Msi, I have witnessed developers (even
experienced ones) stumbling again and again over infrastructure issues and especially over the subject of Msi. In this article I wish to introduce the Msi as
a friendly platform, which - if used smartly - can be of tremendous assistance to any developer.
Let’s start with some general background
The Msi platform was developed by the Office Product Group, after the guys over there had realized that most of the customer support issues that they had been handling were due to faulty installation. The development process of the Msi was a pioneering effort, with limited resources. It took some time for Microsoft to acknowledge the importance of it and designate the required resources for its execution.
In fact, at the beginning of the platform’s distribution, Win9X and Win2k systems did not have the Msi engine, and as a result - the installation media had to include two additional exe files (instmsia.exe and instmsiw.exe) which were used to actually install this engine.
If I was asked to define what Msi is in one sentence, I would describe it as a singleton event-driven database, which includes many tables containing information and objects.
The tables are inter-connected by 1:1 and 1:Many relationships. The Msi registers all the actions of the installation process in order to allow their “roll-back” / retrieval. If you go over an Msi-based log file, you will see that the Msi Engine performs many SQL queries in order to “decide” which actions to perform. None of these actions is being registered in the Operating System until the process is successfully completed (to enable the “roll-back” as well as a clean exit). The Msi will start working only after being executed by the user and it cannot run with more than one installation simultaneously.
Why is it important to use an Msi platform?
Today’s applications are built out of many versioned and un-versioned files. As a result, many dynamic changes need to be made in the end-user machines (wherever a simple XCopy action cannot do the job) and the configuration/installation process becomes more vulnerable to bugs and errors. A research published by IBM reveals that 28% of software projects all around the world fail due to configuration/installation problems. I’ve personally witnesses such projects go down the drain, and that’s one of the reasons that had motivated me to enter the CM/Install world.
Bob Baker states in his excellent book “The Official InstallShield for Windows Installer Developer’s Guide” that “Installation of an application is the end user’s first experience of the product. A bad installation can create a negative impression in the customer’s mind, before he even gets to run the application“. I can safely say that the customer doesn’t really care about the efforts that were put into the application’s development or about how many developers had participated in this project. He wants to see that the application’s installation is completed successfully without any errors or warning messages.
If it doesn’t happen - he becomes suspicious and worried. You should never underestimate the importance of a good first impression!
The next articles in this series will shed more light on the key concepts of the Msi, its development and its best practices for Windows.
|
