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.

I guess you know from your own experience that the “installation effort” in development projects is usually done close to their end. Therefore, when asked to create a certain installation that needs to support the various installation phases, you’ll probably be required to work under a very short deadline.
 
If you want to save yourself many headaches, it is highly recommended to go over the Msi best practices for windows that were specified in previous articles, and to stick to the following guidelines:

1. Examine the binaries that need to be managed by your Msi and try to divide them into groups (“Core installation binaries”, “Language dependent binaries”, etc). Create a detected feature for each group of binaries and determine the “Installation condition” for each feature. If the “Installation condition” property is dependent on what’s set in real time, don’t forget to populate. Place the property population prior to native Msi FileCost CA.
    
2. A dedicated component should be created for each and every managed resource (one component per each resource!!). Don’t forget to set the properties of the various components as explained in previous articles, for each created component (especially the keyfile/keypath property).
    
3. Decide how you want to structure the Features and Components in your Msi. Although it’s possible to remove Components during “Update/Patch” processes, it’s impossible to change the structure of existing features.
    
4. Verify that there is no Component associated with more than one Feature.
    
5. Don’t attempt to replace files located under Windows Directory. The Win2k has a “Windows File Protection” feature which disables any attempt to replace one of these files. Any attempt to install files in the Windows Directory will fail.
    
6. Migrate from earlier versions of Windows.
    
7. Don’t overwrite non-proprietary files with older version of it. Set the “Never Overwrite” property to NO.
    
8. Make sure not to require a reboot inappropriately. (I will later provide an in-depth discussion regarding “Files in Use” and “Restart Manager”).
    
9. Make sure you install to Program Files by default.
    
10. Make sure you install shared files - that are not side-by-side - at their correct locations. The Win2k is able to load two versions of the same file. If you’re about to distribute more than one product and there are “shared core files” between the two products, it will be wise to decide about a shared location between them.
     
11. Properly support the ”Add or Remove Programs”. Do not try to require the user to complete the “Install/Uninstall” process.
     
12. Support “All Users” installations. By setting the “AllUsers” property, the product will be available to all machine users.
     
13. Support Autorun for CD and DVD Medias.

After introducing the Msi in Article 1 and providing some background to its “roll-back” action in Article 2, I would like now to continue and clarify some of its basic concepts.
As you have probably understood by now, the Msi platform registers each and every action during the installation process, and enables its retrieval / “roll-back”. The Msi logs these actions in two separate locations:

• 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.
   
• Registry Key – stores the GUIDs, as well as information about the features and components installed by each product and the relationship between them.

 
Let’s shed some light on the terms “Feature” and “Component” of a product:
   
Product-Feature relationship as wall as Feature-Component relationship are of a “one-to-many” type. It means that each Binary (files / registry / services / fonts / shortcuts / file types / COM registration) Management (install / uninstall / repair) Product includes at least one Feature that has at least one Component.
 
The Feature manages the Components that are installed. The Features are the “logical” elements of the Msi and are stored according to their names (unlike the Components, which are stored according to their GUID). Note: For that reason, you are not required to determine the management condition for each Component in the Msi you create. Instead, you can determine the condition for the Feature containing the components only.
 
A Component, on the other hand, is the “atomic” unit of the Msi. When you work with binary management, your actions are associated with Components. There is no limit to the extent to which a Component uses binary management. It can also manage itself – whether to be installed or not.
 
Out of the many attributes of Components, I chose to focus on those which are most relevant for Msi design:

• Destination: The location of the Components’ resources installation. Note that the destination of a Component has preference over the destination of the Feature under which it is located.
     
• Destination Permissions: Allows you to set the RW permissions for folders created by the Component.
   
• GUID: Each and every Component is defined by a universal and unique GUID. Don’t try to set the same GUID for two different Components.
   
• Shared: Set this property to true for Components which are allowed to be overwritten by other products. A new counter shall be created under: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls with the installed file location.
   
• Permanent: When you don’t want to allow the associated resources of certain Components to be uninstalled, set the “Permanent” property to true for these Components.
   
• 64 bit Component: set this property to true for Components to be installed on 64 bit machines. You should indicate in the “Template Summary” Property the Operating System (OS) type supported by this installation (32 or 64 bit). Although it is possible to bypass this limitation and allow a single Msi to support both Operating Systems, such a move might incur future complications and I highly recommend against it.
   
• KeyPath: You can mark a certain file or registry key as a “KeyPath” within the attributes of an installed Component. The Msi uses the attributes to determine the Component’s need to “repair/upgrade” during the various maintenance modes. It should be noted that even if only the “KeyPath” resource needs to be maintained in a certain Component, the Msi will still execute the maintenance mode for all its binary management tasks.  This rule applies also to Components missing the “KeyPath” resource.

If you want to get the most out of your Msi, you must follow a strict set of rules. I invite you to read the 4th Article in this series, in which I will specify the steps you need to take for the design of an effective and solid Msi.

How a little research can save you a lot of time!

I guess that many of us have experienced the situation when your manager asks you be responsible for the Installation Package development effort just a couple of days before the products release…  I hope that this trend begins to disappear as companies realize that they should treat the Installation Package with as much seriousness as any other feature in the release. In this article, I would like to share with you some of my experiences and the steps I take as the developer responsible for the installation effort.

Each company has a R&D and QA structure suited to its needs. There are companies who have dedicated QA engineers for each feature set and others who have one QA department that handles the entire testing effort.

Unlike many other features of a new release, the Installation Package is one of the features (if not the only) which has full interaction with almost each and every person within the organization: Project Managers, development and QA teams and even the CEO. So, instead of worrying why you’re getting so many installation related demands and change requests, it is highly recommended to identify the various stake-holders relevant to the release and to let them have full participation in the information gathering process. Any action such as a meeting or mail which asks for input regarding the package, whether regarding required components or approving a check list is desirable as long as you end up with a detailed and clear document which describes the nature of the feature and its completion schedule.
 
In addition it is highly recommended to have the support of departmental managers who can sort through various installation package requests which may interfere with the completion schedule, even though these requests are important to the person asking them but are not vital to the current release.

Information Gathering:

1. Should the installation support more than one Operation Systems?
   i.e. Win9X, WinNT, Win2K, WinXP, Vista, Windows ServerX.
    
2. Should the installation support both 32 and 64 bit OS?
   Although it’s highly recommended not to have such installation, many companies are tempted because of management intervention to have one installation which supports both OS’s.
    
3. Should the installation support more than one language?
   If so, then you must take into account the need to support varied language properties when writing files or adding to the registry.
    
4. Should the application support multiple language interfaces?
   In other words, what will be the impact if the user has installed the application using language A and his computer default language is B? Should the application automatically support such cases or should it require user intervention? An additional factor to consider is the interaction with and dependence upon external translation teams who are not necessarily obligated to your completion date.
    
5. Should the installation include additional dialogs other than the default one?
   Many Msi editors are supplying dialog editor capabilities and even ones with Multilanguage support. However, many considerations such as: the information the dialog is designed to gather, where to place the dialog in the installation sequence and various design questions should being raised when adding new dialog into the installation procedure.
    
6. Should the installation support DB management?
   Whilst it is true that few Msi editors are trying to add DB creation and/or maintenance capabilities, questions such as how to backup the DB status prior to the DB execution scripts, when during the sequence should the scripts run, troubleshooting during scripts failure etc., should have in-depth consideration.
    
7. Should your installation include any third party installations?
   Many installations include various third party installation scripts as prerequisites or because they are developed from various installation packages from numerous sources. As mentioned in a previous article regarding Msi packages, it is highly recommended not using the Msi nested installation CA. Note that Msi 4.5 which supports XP as well, is released with a new chaining mechanism to support such cases. For executable packages, it is recommended that you consider using a “smart” self-extractor which will execute the packages one by one. The impact of Vista OS support should also be given in-depth consideration regarding silent installations and the execution of the application at the end of the procedure. (The only way to execute a silent installation in Vista is by using elevated privileges; hence the applications which will be executed at the end of the process will be marked as having elevated privileges as well even though they were executed from the non-elevated Msi sequence).
    
8. Many installations include various third party installations as prerequisites or because they are developed from various installation packages from various sources. As mentioned in a previous article, do not attempt to use any the Msi nested installation. It is recommended that you consider using a smart self-extractor which will execute the packages one by one. The impact of Vista OS support should have in-depth consideration regarding silent installations and the execution of the application at the end of the installation. (Installation programs run under these conditions will be given an “elevated” flag by the Vista OS and will demand Elevated Administrator privileges in order to successfully complete the installation process).
    
9. Which sequences should the installation support?
   Many companies do not support the various Msi maintenance sequences (repair, change, upgrade, patch) by definition. But, if you’re planning to have this ability at the future, it is highly recommended to include the infrastructure for them even though you’re not using it currently!

It is vital to take into consideration that for any item from the list above that is true of your installation package, in addition to the time taken in the development stages, adequate testing procedures must be set up and sufficient time allowed for full testing before the final release.
 
Do not assume that once the installation is successful in one scenario (platform, OS, Language) it will be successful in others as well. It is highly recommended in such cases that instead of managing one installation per scenario (platform, OS, Language) or having one installation package that will manage all the processes, to use the Msi transformation mechanism.

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?
      

Part of the development cycle for any installation package is the initial planning stage. We spend a lot of time and effort on this first process as this will determine the character of the final package.

However, even when the planning stage is completed and work is progressing on the development of the Installation Package, we often have the feeling that maybe there is something we missed, something we could have done differently. That’s the purpose of this post, to help developers focus on some of the more important aspects of the planning process and to be able to distinguish between a good installation package and an excellent one.

Perhaps the best way to begin the development of an installer package is, at the very beginning, to imagine yourself as the end user, the person installing a program using your installer package. It is important to remember that, even though the time spent interacting with the installer package is relatively short, it is also the time when the user is most concerned and uncertain as to the final outcome.

I think that almost every user (myself included) has often felt at some stage during the installation process that his PC has frozen or is about to burst into fire and wonders if he should press the “reboot” button.

In order to make the process less painful and anxious for the end user, I recommend taking the following actions:

1. Remove un-needed dialog: sometimes we leave a redundant dialog box in the setup process. Make sure to avoid this – the end user might think that his installer package is missing an element or is corrupted. In any event, it is confusing and leaves a bad impression.
     
2. Ensure that your dialogs display the default values: when asking for a user response during the installation process, make sure that the default values are show automatically when the dialog GUI is displayed. This is the industry standard!  Your installation should succeed (i.e. successful application execution with general features) even if the user just kept pressing the Next button!
    
3. Ensure that the installation package supports a repair option: When an application has been corrupted and is no longer usable, having to uninstall and then reinstall can be an annoying and tedious process. If your installer package has a “Repair” option, this can be very helpful and less frustrating to the end user.
     
4. Make sure to save user settings: many programs have comprehensive and regular upgrade packages. However, often the implementation of these upgrades can be marred because the upgrade process erases previous user settings. Therefore, when developing an MSI based upgrade package, it is very important to allow the user to retain previous settings.
    
5. Spare the user from un-wanted applications embedded within the MSI package: many installation packages are actually a collection of installation scripts built by teams located in other locations. In cases where not all segments of the installation package are vital, it is essential to allow the user the option to choose which parts to install and which not.  In addition, make sure that the installation will succeed whatever segments the user chooses to install or not install.
    
6. Spare the user from un-needed upgrades: whilst it is true that a major upgrade replacing the installed software in its entirety is the easiest maintenance scenario for the installation developer, I recommend using a Patch to modify installed software. This is a much simpler procedure for the end user and less intimidating especially when working with Vista (which will save the user from additional UAC dialog due to the sticky elevation mechanism).
    
7. Try to avoid confusing warning or error dialogues: unfortunately many installation developers are not doing enough to make sure the user will not have to deal with un-clear warnings or error messages. This includes the “File in Use”\”Restart Manager” pops-up that can appear when the Msi package attempts to update or uninstall files being used by the application.
    
8. Eliminate unnecessary reboots: make efforts to eliminate unnecessary computer reboots during the installation. Apart from the time element, many users have open and unsaved files or open web pages with information that will be lost if the computer reboots.
    

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.