Best Practices Windows Installer, Application Compatibility and Deployments

Best Practices to follow while Packaging Applications

Hard-coding should be avoided

In an MSI, Hard coding should be avoided to the maximum and should be replaced by properties. For e.g. instead of “C:\Program Files\…”, property “ProgramFilesFolder should be used.

Least Use of custom actions involving 3rd party tools

Any changes which are being made to the system during an installation should possibly be made through an MSI involving least use of 3rd party tools. For e.g. If an UI Installation needs to created, it should be done through MSI Dialogues not through Visual Basic exe’s. If a file has to be installed conditionally, same should be done through MSI’s functionality not through VB Scripts.

Deletion and allocation of resources (files, registries) to proper components.

During Setup capture, Wise package Studio, captures lot of junk registries and usually you will find all these registries in a component by name “registryXX”.
This component needs to be carefully looked at since this component will have registries which otherwise should belong to other components. For e.g this component will have registries for e.g HKCR\CLSID\{GUIID} or HKCR\Interface\{GUIID}.If there is a dll in your application and registration of this dll has this GUID, then this registry should be moved from this component to the component having this dll else this registry is categorized as junk registry and needs to be removed.

 Ini Files should be retained as INIFile Table Entries not as Files, to the extent possible.

Ensure that any INI file changes are recorded in the INI file table, rather than just as files in the file table. This will ensure that INI files are edited if they exist already, rather than replaced with the version within the MSI Package.

Shortcuts should be made as “Advertised” shortcuts to the extent possible.

This is to ensure Self Healing.

DLL’s should be registered through Advertising Tables to the extent possible.

This is to ensure Self Healing and minimize registry conflicts.

As soon as you realize that the source installation is an MSI or installs an MSI embedded in it, it should be scripted as Vendor MSI.There should be no empty components in the MSI.

 Only COM Dll’s should be isolated.

If any custom actions are used, “In-Script” options and “Processing Options” need to be set correctly for them.

During Setup Capture

if it’s observed that lot of .INI Files have got captured, it’s better to exclude the INI files from the capture and then a second capture can be taken just with INI files or the INI files can be added as files, else the capture will take several hours and some times may not complete.

it’s possible that .INI Files, .INF Files, .HLP Files or .CHM Files do not get captured properly. To make sure all these files are present in MSI, it’s better to compare the size of the application folder in target machine (where application is installed) with captured folders after Setup Capture.

In some applications, it’s required to do the capture in some specific accounts and Wise can’t be installed in that account. In such cases it’s better to use the Wise as “run as” rather than going for some other capture techniques.  

Note: Run as account should be the account in which Wise is installed.


Lot of CHM files

 When there are lot of CHM files need to be added in the script which might have missed during capture, add it to the components directly rather than adding through Installation Expert. The reason for this is if you add through Installation expert, then the CHM files will be moved to the components, which is already having some CHM files, getting installed in some other folder.


Best Practices How-to Windows Installer, Application Compatibility and Deployments

Capture configuration Entries through Gap-Capture

This tip will shine some light on the concept of performing a “Gap Capture”. Let’s start with a simple equation: GAP CAPTURE = SOURCE APPLICATION – CAPTURED MSI.

Basically, a Gap Capture is the difference between a Source Application and Captured MSI.

When do we do this??

You have done the setup capture but your MSI fails in Functionality Testing. One reason could be that some files or registry is missing in your package. To capture the LEFT OUT entries, we need to do GAP capture.

How do I do this ??

1. Install Captured MSI of the Application on your system.
2. RUN Setup Capture and take the SnapShot.
3. Install Source Application over it.
4. Now finish the Capture (SnapShot of OS+MSI+Source Application)

What you’ve captured in the WSI is now a GAP Capture.

What Next??

First re-build the machine and install your earlier packaged MSI. If the Gapcaptured content is a registry entry or a file. just add this entry in the machine and launch the application shortcut. If it launches fine..its a Bingo!

Now, add this content to the MSI. Many a times, it can also be beause of an autoupdation of an ini file. In this case, install the source application and extract the ini files into your package and check for its functionality. I reckon, these steps will help !!!

Best Practices Windows Installer, Application Compatibility and Deployments

How to add Assemblies to Global Assembly Cache (GAC)

Installation of assemblies should not be dealt using gacutil.exe (Custom action) in an application installation suite. Gacutil is not designed to be used during installation. Gacutil.exe works, but it is a developer tool, and developer tools go into SDKs and not runtime packages typically. It isn’t really appropriate to put more tools into the runtime because that causes it to get larger, which makes it more difficult for applications to redistribute because of increased download, size, etc.

In general, installing an assembly to the GAC is an application deployment activity, and is most often done during application setup. One should use Windows Installer to install your application. Starting with version 2.0, Windows Installer has built-in functionality to install assemblies to the GAC – the MsiAssembly and MsiAssemblyName tables in particular. Its always better to use a MSI as an installer and directly authoring files, registry and GAC installation steps using built-in Windows Installer functionality instead of using a batch script, regsvr32 and Gacutil. We can gain a lot of benefits from using an MSI (clean rollback; uninstall, serviceability, deployment options, etc). Therefore we should use this built-in functionality to handle GAC installation and un-installation.

This means that if we want to obtain Windows Vista Logo certification for our application, we should use Windows Installer and the built-in GAC installation functionality for our setup.

Reference: Aaron Stebner’s WebLog

Best Practices Microsoft Windows Installer, Application Compatibility and Deployments

Microsoft Best Practices & Standards: Application Packaging

Here are a few tips I picked up from Microsoft about how to “color inside the lines” when using any tool (including Wise Package Studio) to create an MSI.

  1. Match components in previous versions of the MSI:
    Key path resource matches a resource in previous .MSI list
    Match component layout of previous .MSI
    Set component key to match previous version.
  2. Add all executable files to their own components
  3. Create new component for the resource
  4. Add all .TLB files to their own components
  5. Group matching .HLP and .CNT files together
  6. Group matching .CHM and .CHI files together
  7. Put registry keys associated with files or components in matching components.
  8. Put current user registry keys in their own component
  9. Put non-current user registry keys in their own component.
  10. Group all non-executable files to their own component
  11. Name new non-advertised shortcuts by destination directory.
  12. Group non-key path resources by resource type
  13. Create new components for resources not matching other criteria.
  14. Set component key to table name of key path or the first resource.

Hope these little guidelines helps!

Best Practices How-to Microsoft Tools Windows Installer, Application Compatibility and Deployments

How to create a Windows Installer Patch using Wise Package

Step 1: Launch the Patch Creation tool from within your Wise product. The Patch Creation tool’s Welcome dialog appears. This dialog offers an outline of the steps for creating a patch.

Step 2:
Read the information on the Welcome dialog, and click Next when finished. The Specify Patch Settings File dialog appears.

Step 3: The radio buttons on the Specify Patch File Settings dialog indicate whether to create a new patch file or Open an existing patch settings file. A patch file (.PCP) stores settings from the Patch Creation tool, such as the names of the previous and new .MSIs and whether to include whole files or file patches when compiling the patch. For this exercise, select the radio button to create a new patch file and click Next. The Specify Previous Versions dialog appears.

Step 4: Use the Specify Previous Versions dialog to add entries for each of the previous versions of an installation that the latest version can patch. Click Add to add a previous version. The Previous Version Details dialog appears.

Step 5: Click Browse to browse to the .MSI for the previous version of your application. Click Open after locating the .MSI.

Step 6: Make any desired changes on the Previous Version Details dialog. The settings in the Validation section of the dialog indicate the requirements of the previous installation on the destination computer in order to install this patch. Please view the online help by pressing F1 on the Previous Version Details dialog for more information about the various fields.

Step 7: Click OK when finished making changes on the Previous Version Details dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI and the Specify Previous Versions dialog shows a target path pointing to a temporary directory where the extracted .MSI resides.

Step 8:
Add other previous versions if applicable, then click Next on the Specify Previous Versions dialog. The Specify Upgrade Version dialog appears.

Step 9: The Specify Upgrade Version dialog shows the path to the .MSI that upgrades the previous versions enumerated on the Specified Previous Versions dialog. When launching the Patch Creation tool with an installation project already open, the Upgrade MSI path field contains the path to the .MSI for the current installation project. Click Browse to browse to the upgrade .MSI if the Upgrade MSI path field doesn’t already contain the correct information.

Step 10:
Click Advanced to display the Advanced Upgrade Version Details dialog. This dialog shows the Patch GUID and a field for Previous Patch GUIDs to replace. Please view the online help by pressing F1 on the Advanced Upgrade Version Details dialog for more information about the fields on the dialog. Click OK when finished making changes to the Advanced Upgrade Version Details.

Step 11: Click Next on the Specify Upgrade Version dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI to a temporary directory, and then the Compile Patch dialog appears.

Step 12: The Compile Patch dialog shows several options for compiling the patch. The first field is the name of the Output .MSP file. Browse to the location where to store the .MSP file, or type in the full path including the file name.

Step 13: The Advanced Settings on the Compile Patch dialog determine whether to create file patches or to use entire files, whether to allow the Product Code or Version Number to differ between the previous and upgrade, and whether to create a log file. Mark the checkboxes for these options to enable them.

Step 14:
The Multi-patch Media settings indicate the starting file sequence and disk ID numbers as well as the volume label for the .MSP and the prompt that displays when the application needs to be repaired. Again, please view the online help by pressing F1 on the Compile Patch dialog for more information. Note that the Volume Label on this dialog must match the volume label on the CD or other write-protected media that distributes the patch. Click Next on the Compile Patch dialog to continue the patch creation process.

Step 15: The Patch Creation tool begins creating the patch. A dialog might appear, saying “ProductCodes between Target and Upgraded images do not match; do you want to proceed anyway?” Click Yes to continue creating the patch, or click No to stop. Another dialog might appear, saying “ProductVersions between Target and Upgraded images do not match; do you want to proceed anyway?” Click Yes to continue creating the patch, or click No to stop.

Step 16: When the Patch Creation tool has finished creating the patch, the Compile Patch dialog says Patch creation completed and has a View Log button. Click View Log to view the patch creation log, or click Finish to close the Patch Creation tool.


Best Practices How-to Microsoft Windows Installer, Application Compatibility and Deployments

MSI Packaging Guidelines and Best Practices for Windows 7 / Vista

Here are few points which would prove handy while re-packaging an application for Vista / Windows 7.

1. If you must make a change on the system via a custom action, ensure that the custom action is deferred and the msidbCustomActionTypeNoImpersonate bit is set. This will ensure that the custom action inherits elevated privileges from the installed

2. Place all your custom actions in the Execute Sequence to ensure that they are invoked during silent mode and use appropriate conditions on the custom actions to only run when intended

3. Test your application for a locked down user. If necessary, give the user permissions to access folders and registry keys that the application tries to write to via the Locked Permissions table. Do not open higher level folders such as C:\Program Files, C:\Windows or C:\Windows\System32 for locked down users. Instead, set permissions on the exact sub-directory that the application needs access to:

4. AdminUser property commonly used to check for admin rights will not work in UAC. Microsoft has decided to set this to TRUE by default for Application Compatibility reasons. Use MSIUSEREALADMINDETECTION property instead.

5. Add installation logic that was not captured by SetupCapture. Example: Launch conditions that check for system requirements.

6. Turn off Virtualization feature. This will ensure that, duplicate files and registries are not created. This mainly happens to the applications which need a launch. The keys which are virtualized can be removed from the package as well.

7. Add support for Vista-specific features 🙁 This can be found in the “Windows Installer Options” dialog of Installation expert in WPS 7.0)

a. Disable the User Account Control (UAC) prompting for standard user installations.

b. Set options for Restart Manager.

8. Set Windows Installer logging options to provide verbose output. The installation log can provide valuable information about why an installation fails.

9. Remove 16-bit features from packages that will run on the 64-bit version of Windows Vista, if they are not part of the application’s primary functionality.

10. Remove all WRP components from the MSI package. If the installation installs a file that would otherwise be installed to an area that is protected by Windows Resource Protection (WRP), you can do one of the following:

a. Delete it from the installation and test the application with the version that is on the destination computer. However, if you do this, your application can fail if the protected file is updated or changed in the future.

b. Isolate the protected file so it is installed to a different location.

11. Fix installation-related errors that you find while performing installation and functionality tests.

12. Make other changes that are not related to Vista but are required as Customers standards.

13. Resolve CA’s which involved Nested Installation. This will throw an error while deployment.

14. Impersonation should not be used when running setups on Windows Vista. Edit the custom action and change its In-Script Options property to Deferred Execution – System Context. Test to verify that the custom action runs in this context.

15. Edit the custom action to add a description. The Windows Installer Editor documentation contains information you can use to document Wise custom actions

16. Any property beginning with MSI cannot be used. Hence avoid using the same.

17. Components cannot have a dummy GUID; it’s a best practice to generate one.

Best Practices How-to Microsoft Windows Installer, Application Compatibility and Deployments

Best Practices for Windows Installer MSI Custom Actions

The Windows Installer has many built-in actions for the installation of applications. However, when a packager of an installation package finds it necessary to write a custom action. There are some best practices which have to be followed for optimal execution.

  • Custom actions that use sensitive information should not write this information into the log.
  • Custom Actions must not attempt to set a System Restore entry point from within a custom action.
  • Return error messages from custom actions and write them to the log to facilitate troubleshooting custom actions.
  • Do not change the system state from an immediate custom action. Custom actions that change the system directly or call another system service must be deferred to the time when the installation script is executed.
  • Every deferred execution custom action that changes the system state must be preceded by a rollback custom action to undo the system state change on an installation rollback.
  • Custom actions that perform complex installation operations should be an executable file or dynamic-link library. Limit the use of custom actions based on scripts to simple installation operations.
  • Make the details of what your custom action does to the system easily discoverable to administrators. Put the details of registry entries and files used by your custom action into a custom table and have the custom action read from this table.
  • A custom actions should not display a dialog box. Custom actions requiring a user interface can use the MSIPocessMessage function instead
  • Custom actions must not use any of the MSI functions like,
    MSIVerifyLog etc…
  • If the installation must be capable of running on a Terminal Server, test that all your custom actions are capable of running on a Terminal Server.
  • To have a custom action run when a particular patch is uninstalled the custom action must either be present in the original application or be in a patch for the product that is always applied.
  • Custom actions should not use the UI level as a condition for sending error messages to the installer because this can interfere with logging and external messages.
  • Use conditional statements to ensure that your package correctly runs custom actions, does not run custom actions, or runs alternate custom action when the package is uninstalled.
  • Test that the package works as expected when uninstalling custom actions.
    If the installation must be capable of being run by users that do not have administrator privileges, test to ensure that all the custom actions can be run with non-administrator privileges.
  • Custom actions require elevated privileges to modify parts of the system that are not user specific. The installer may run custom actions with elevated privileges if a managed application is being installed or if the system policy has been specified for elevated privileges. Any custom actions the require elevated privileges must include the msidbCustomActionTypeInScript and msidbCustomActionTypeNoImpersonate Custom Action In-Script Execution Options in the custom action type.
Best Practices Windows Installer, Application Compatibility and Deployments

MSI Package Validation using ORCA

ORCA provides a graphical interface to the package validation functionality available as part of the MSI SDK and in several third-party tools. Validation can flag many common problems in MSI packages by analyzing package data for invalid cells or combinations of cells that are not consistent.

Validation is performed by one or more Internal Consistency Evaluators, that are organized into CUB files. Several standard validators and CUB files are provided as part of the Platform SDK. ORCA can also use custom validators and CUB files.

Choosing a CUB File

You can select a CUB file for use during the validation run in three ways:

Select a CUB file from the drop-down list.
The list contains all CUB files registered on the system for use in validation.
Type a full path to the CUB file in the edit control.
Click the “Browse” button and locate a CUB file.
The default value for validation can be changed by choosing Options… from the Tools menu and changing the Default ICE File value on the Validation tab.

Selecting ICEs to Run

You can limit the set of ICE validators that run from a particular CUB file by changing the value in the ICEs to Run field of the validation dialog.

The set of validators to run can be specified in two ways:

Specifying no value selects the default set of ICEs from the CUB file.
A set of individual ICEs can be selected by specifying the ICE names, separated by a colon character (‘:’). The set of ICEs available depends on the CUB file selected.
The default value for this field can be changed by choosing Options… from the Tools menu and changing the ICEs to Run value on the Validation tab.
Running Validation

To run validation, click the Go button. ORCA executes the specified validators in the selected CUB file, validating the current database, including any changes to the database that have not been saved.

Filtering Information Messages

To not place information messages from the validators in the list of results, uncheck the Show “INFO” Messages option. This option can be toggled while validation is running, in which case, it affects messages generated from that time on but not messages that have already been generated.

Warning and information messages can be filtered by default by selecting the appropriate options in the Tools\Options configuration dialog box on the Validation tab.

Placing Results on the Clipboard

To copy the results of a validation run to the clipboard for pasting in another application, click the Copy Results button.

Using the Validation Pane

When the validation dialog box is closed, all warnings and errors in the validation window are copied to the validation pane at the bottom of the ORCA window. To show or hide the validation pane, choose Validation Pane from the View menu. Hiding the validation pane does not erase the contents.

To jump to the location of an error, select the error by clicking on it or using the arrow keys in the window to move to the desired error. The table list and table view immediately jump to the exact location of the error that was reported by the validator.

If a table or row that contains an error is deleted, any validation errors associated with that row are deleted from the validation pane.

The data in the validation pane is replaced each time the database is validated.

Examining Table and Cell Errors

To examine the errors associated with a specific cell, right-click on the cell and choose Errors…. The error information associated with the cell appears in a small dialog. If more than one error is associated with the cell, you can click the Previous and Next buttons to switch between the different errors.

To examine the errors associated with a table but not a specific cell, right-click on the table name in the table list and choose Errors…. The error information associated with the table appears in a small dialog. If more than one error is associated with the table you can click the Previous and Next buttons to switch between the different errors.

The information presented in the Errors dialog box is the same information available in the validation pane.

If a table does not exist in the database but contains a validation warning or error (such warnings and errors usually indicate that the table or a value within the table is required but not present), a Shadow Table appears in the table list. This table is used to provide access to the validation errors or warnings associated with the table, but does not indicate the presence of the table in the database. When a shadow table is selected, the table view pane that normally displays the contents of the table does not contain any table information and indicates that the table does not exist in the database.

If there are no errors associated with the cell or table, the Errors… option is disabled.

Cancelling Validation

To cancel the validation, press the Cancel button. No additional validators run and a cancel request is sent to the currently running validator. Some ICE validators acknowledge the cancel request and stop immediately. Other validators run to completion before accepting the cancel request.

Best Practices Microsoft

Windows 7 – File and Registry Redirection : Impact on MSI Packaging

The basics of this feature is explained in the article Folder Virtualization Concepts in Windows Vista.

Impact in MSI Packaging
Files in a registry key can be found twice in your installation. Especially if the application has to be launched to customize options and settings.

Possible Work-around
During Setup-Capture:

Virtualized resources needs to be merged with the original files and the virtualized resources can be deleted from the installation resources. If file and registry virtualization is enabled on the default user environment, you will need to test the application with two different default user accounts. Check if resources from the application gets virtualized and that those contents will not affect the proper functionality of the application.

The best practice is to disable the file and registry virtualization. Microsoft does not guarantee this feature will be in future releases of Windows. If a file or registry key needs permission changes, use the LockPermission table or use a custom action to modify the related security descriptor of those resources. If the user has the permission to modify the resources, it won’t be virtualized.

It’s recommended to use the latest release of a product that supports Vista. Applications following the Microsoft development guidelines for Vista compliant applications, are modifying resources in the user profile where virtualization will not take place.

Best Practices Windows Installer, Application Compatibility and Deployments

Application Packaging Advantages & Installer Benefits

Application packaging bundles applications and operating systems into a single file called a distribution unit (.msi), which makes it easier to deploy and install them on user’s computers. Packaging reduces the total cost of ownership for the customers by enabling them to efficiently install and configure the applications. This results in an application package, which provides the product with new capabilities like advertise features without installing them, installs products on demand, add user customizations etc.

Advantages of Packaging(creating MSI packages)

    1. Customize Applications to suit the user needs.
    2. Simplify the Installation and Un-installation Procedures.
    3. Saves Time in both Installation and Un-installation.
    4. Once packaged, applications can be quickly installed on a range of desktops in multiple locations, saving administrative costs, simplifying the manage of licensing fees and minimizing support and repair expenditures.
    5. Saves Space of the product by doing apt modifications to applications.
    6. Has a great flexibility of obtaining the lost files through a phenomenon called Self Heal, this reduces the down time of application. If a critical file (a .DLL or .EXE file, for example) that is part of the distribution is corrupt or is deleted, the user can be prompted to repair the installation by presenting the original .MSI distribution. Additionally, if the installation media is available (for example, on a network share), the repair simply happens automatically.
    7. Can be advertised. So that on demand installation could take place.
    8. Upgrading of the application can be done with ease.
    9. Clean installation and Un-Installation is achieved by a process called Roll-Back.
    10. Simplifies management of new user set-up along with the revision and distribution of software repairs and new applications to existing users. Application recovery can also be improved.
    11. Helps eliminate uncontrolled software downloads and installation, enables applications to be safely removed and reduces non-business traffic on a corporate network.
    12. Using .MSI format, can automate software distribution process and ensure that the installation doesn’t break other applications that have already been installed.
    13. Application is installed via an OS service.
    14. State management is maintained. In the past, it’s been difficult to know whether an application is installed on a machine. You would have to query for a .DLL with a specific version number or determine whether an .EXE file with a specific name was present. Windows Installer provides an application programming interface (API) that lets programmers and administrators see whether a specific application is installed on a machine.
    15. Scriptable API. This whips together a VBScript to help us with the MSI file manipulations. The API to manipulate MSI files is so powerful that it can create, validate and update packages, trigger installs and uninstalls, examine the MSI repository data on computers, and perform some custom actions.
    16. Served installs. Because MSI files can be housed in a share point and delivered via a server, we can keep our installation files all in one place or move them around — closer to the users if necessary.

Hope this article helps the people who keep their first steps in packaging… 🙂