Easy Setup

After introducing the Msi platform in Article 1, I would like now to take a deeper look at its “roll-back” feature.
 
The idea of having an Msi platform is to register all the actions during the installation process and enable their retrieval (“roll-back”). Each and every action is logged in two separate locations:

1. c:\WINDOWS\Installer – stores a transformed copy of the original Msi, according to the actions performed during the installation process. This copy is later used, for example, to enable “Remove/Repair” and other maintenance sequences.
      
   In addition, this file stores the PackageCode. Most Installation Editor Programs define this code as default behavior and use it to determine when to run “Update/Maintenance” Mode. (The code can be queried by either opening the Msi through the editor, or by right clicking it and then selecting the “Properties Summary” tab or the “Revision Number” field.
      
2. Registry Key – stores the GUIDs, as well as information about the features and components installed by each product and the relationship between them, as follows:Upgrade Code: A unique GUID defining the “family” of the product. This code is registered, after the installation is successfully completed, under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes.
     
   Product Code: A unique GUID defining the installed product. This code is registered under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\[user identifier]\Products and as a sub-key under the UpgradeCode. The [user identifier] marks the unique GUID which is given to each user of the machine. The extra sub-key helps to distinguish between per-machine and per-user installed products.
     
   Features: The name of each installed feature and its encrypted data are listed under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\[user identifier]\Products\[Transformed Product Code]\Features.
    
   They supply the relationship information between the installed components of each product.
    
   Components: The identifier GUIDs for all the components of each installed product are listed as a sub-key under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\[user identifier]\Components\[Transformed Product Code].
    
   They supply the relationship information between the installed components of each product. Note that the GUID registered here is the transformed one.
     
   Patches: The list of patches installed for each product, and their properties, are listed under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\[user identifier]\Products\[Transformed Product Code]\Patches\[Transformed Patch Code]/
    

Some of the terms mentioned in this article, such as “Feature”, “Components” and “patches”, will be clarified throughout the next articles of this series.

Criteria for evaluating and choosing the correct development tool for your project.
 
A question often asked by developers is which Msi program, supplier or system is best suited to the company’s needs? As always, the answer is not a simple one and involves many factors, such as cost, ROI, customer support etc. The final decision can often be a critical one that will impact on the company in the future, and so, should not be taken lightly. In this post, I would like to share with you some of the conclusions I have arrived at after having to make such a decision a number of times.

Generally speaking, the idea is to gather answers to specific questions regarding the programs’ features (you can add or remove questions as you choose to suit your particular situation) and place them into a matrix for comparison. You should then rank each program feature on a scale of one (lowest) to ten (highest). It is a given that you are the one who decides which features are more important than others and score them accordingly. At the end of the process, the highest scoring program should be the one you select. Using this system enables you to make a decision that is uninfluenced by you or your colleagues’ personal ideas and opinions.

Information Gathering:

1. How many programs are there available in the market? By executing a simple internet search you can find many solutions and products upon which to base your research.
    
2. What the cost of the program and/or license per computer? Many companies have various licensing schemes. Many of them publish prices and licensing information on their website. If not, then you can always mail or phone for a quote.
    
3. How complex do you need the editor to be? Choose a product that has all of the features you need but not too many that you have no use for. Check out freeware or “Light” editions of commercial products, many of them are excellent and provide a wide range of tools that may be more than enough for your needs.
    
4. Does the selected application have a good, helpful customer support team? Customer and technical support can be provided in many different ways. Sometimes none is provided at all. In any event, is the support scheme available for the product, one that suits your needs and demands?
    
5. What is the application’s learning curve? You don’t want the learning process for the application to be a bottleneck for each new addition to your development team.
    
6. Does the application have understandable and logical Help documentation – written, on-line or built-in? Can it be mastered easily by the user or will it be necessary to employ a support person to integrate the application in your company?
    
7. Does the application support the creation of multiple language package creation in the event that additional languages are needed?
    
8. Does the application allow for easy update, upgrade or Patch creation if necessary?
    
9. How easy is it to use the application to build an automated procedure – if at all?
    
10. Does the application support a simple Find and Change procedure?
     
11. How would you rate the program and final application implementation and performance?
      

Pantaray Research have released SuperOrca MSI Editor - A Developers tool that enables easy editing of MSI Installer Packages. 

Limitations in existing Windows Installer tools mean that the developer must edit Windows Installer package (.msi) files directly. SuperOrca is an MSI Developer System that is an alternative to Microsofts’ Orca MSI. Using SuperOrca developers can examine and modify with ease an MSI database. 

SuperOrca from Pantaray is more powerful, smaller, easier to use and install than Microsofts’ Orca MSI and can be downloaded totally free of charge from Pantarays’ site with just a few clicks of your mouse.

SuperOrca MSI Editor has received an excellent review from a professional in the MSI development field.

The new SuperOrca from Pantaray Research can serve the developer installation community as well as IT managers by facilitating viewing and changing any MSI installation. Read More

After introducing the Msi platform in Article 1, I would like now to take a deeper look at its “roll-back” feature.

The idea of having an Msi platform is to register all the actions during the installation process and enable their retrieval (”roll-back”). Each and every action is logged in two separate locations:

1. c:\WINDOWS\Installer - stores a transformed copy of the original Msi, according to the actions performed during the installation process. This copy is later used, for example, to enable “Remove/Repair” and other maintenance sequences.

In addition, this file stores the PackageCode. Most Installation Editor Programs define this code as default behavior and use it to determine when to run “Update/Maintenance” Mode. (The code can be queried by either opening the Msi through the editor, or by right clicking it and then selecting the “Properties Summary” tab or the “Revision Number” field.

2. Registry Key - stores the GUIDs, as well as information about the features and components installed by each product and the relationship between them, as follows:

• Upgrade Code: A unique GUID defining the “family” of the product. This code is registered, after the installation is successfully completed, under: HKLM\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Installer\ UpgradeCodes.
  
  
• Product Code: A unique GUID defining the installed product. This code is registered under: HKLM\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Installer\ UserData\ [user identifier]\ Products and as a sub-key under the UpgradeCode. The [user identifier] marks the unique GUID which is given to each user of the machine. The extra sub-key helps to distinguish between per-machine and per-user installed products.
  
  
• Features: The name of each installed feature and its encrypted data are listed under:HKLM\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Installer\ UserData\ [user identifier]\ Products\ [Transformed Product Code]\ Features.
  
  

They supply the relationship information between the installed components of each product.

• Components: The identifier GUIDs for all the components of each installed product are listed as a sub-key under: HKLM\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Installer\ UserData\ [user identifier]\ Components\ [Transformed Product Code].
  
  

They supply the relationship information between the installed components of each product. Note that the GUID registered here is the transformed one.

• Patches: The list of patches installed for each product, and their properties, are listed under: HKLM\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Installer\ UserData\ [user identifier] \Products\ [Transformed Product Code]\ Patches\[Transformed Patch Code]/

Some of the terms mentioned in this article, such as “Feature”, “Components” and “patches”, will be clarified throughout the next articles of this series.

Software installers are extremely valuable to the software industry, as the first impression users receive when dealing with new software is its installation process.

Two major technologies are used for software packaging: The first is the traditional EXE and the second is Microsoft’s MSI.

Both technologies are marketed side by side, as each one has its distinctive advantages and disadvantages. One of the industry’s main challenges is to manage and combine the two technologies into one product.

• EXE - The traditional EXE is perfect for consumer applications that are distributed online or on CDs, as well as for internal company packages.

Most of the popular applications that can be downloaded from the net are EXE based. EXE provides enormous flexibility and a fully customized installation platform for popular applications such as Google, Skype and others.

There are many companies that provide EXE installers, such as “InstallShield”, “Wise” and “Pantaray Research”, while many other companies choose to develop their own internal installers.

The main drawback of the EXE installers is that if they are not developed professionally, the installation might cause conflicts in the Windows Operation System.

MSI – This platform is more applicable to IT Managers in enterprises, who wish to control the software installations throughout the entire organization. The MSI provides software packaging, patch testing, license management etc., enabling IT Teams to increase application reliability, improve productivity and reduce licensing costs.

The Windows Installer (MSI) is an engine used for installation, maintenance and removal of software on newly Microsoft Windows Systems. The installation’s information, and often the files themselves, are packed in installation packages, commonly known as “MSI Files”.

Microsoft encourages third parties to use Windows Installer as their basis for installation processes, thus ensuring correct synchronization with other installers and keeping a consistent internal database for installed products. The reliable operation of important features such as “rollback” and “versioning” (which prevents “DLL Hell”…) depends on a consistent internal database.

The MSI, which is supplied by companies such as “InstallShield”, “Wise”, and “Pantaray Research”, provides more protection from unauthorized actions and from conflicts in the Operating System, but at the same time considerably reduces the flexibility and richness of the installation. MSI installation files also tend to be larger in size than equivalent .zip or .rar files (or self-extracting .exe), due to the fact that the file’s internal database is not compressed.

As each technology carries its distinct values in different areas of software installation, one of the industry’s main challenges is to develop one overall tool that may provide the “best of both worlds”, for enterprise and consumer applications.

Although the installation processes of each technology are different and cannot be unified, the user interfaces for installations can be united, thus making life much simpler for the developer, who can perform all the needed actions and directions of the packaging process, and then choose whether to compile in MSI or in EXE. All the directions regarding the files and their destinations will be shared in the same GUI.

Pantaray Research took upon itself the challenge of providing the same installation sequence for both technologies, and succeeded to develop the perfect GUI enabling either EXE or MSI. All the programmer needs to do is to follow all the necessary installation instructions and then to decide whether to compile the setup in EXE or MSI.

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.