Easy Setup

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.

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.