Package Validation: Benefits and Directions
Here's a very nice piece on the how's and why's behind validating your installation packages. Dive into the deep end and get a good fast overview of validation and how to get the most out of it.
What is Validation?
A tool that checks Windows Installer installations to ensure reliability, internal consistency, and compliance with standards. Error checks are performed based on rules in validation modules, including Microsoft's Application Specification for Windows 2000.
Validation scans the database for errors that may cause incorrect behavior in the context of the entire database. One can validate the sample package using Orca or Msival2.exe (both are provided with the Windows Installer SDK). Validate both the merge module and the MSI before merging. The validation tables of the MSM and the MSI must be consistent for the merge to be successful.
Why Validate a MSI package?
Attempting to install a package that fails validation can damage the user's system. Always run validation on packages before attempting to install them, and rerun validation after making any changes to a package.
It is strongly recommended that one should run validation on every new or newly modified package before attempting to install it the first time. Most Windows Installer authoring tools contain the facility to perform package validation.
How is Validation Done?
Most Windows Installer authoring tools use Internal Consistency Evaluators, also called ICEs, to perform package validation. ICEs are custom actions written in VBScript, or in JScript, or as a .dll or .exe. When we run an ICE, it scans the package's database to identify entries that are valid individually but might cause incorrect behavior in the context of the entire database.
ICE custom actions return four kinds of messages:
- Informational. Provide information from the ICE and do not indicate a problem with the database. Often the information is about the ICE itself, such as a brief description. These messages can also provide progress information while the ICE runs.
- Warnings. Report database authoring that causes incorrect behavior in certain cases. Warnings can also report unexpected side effects of database authoring For example, entering two separate conditions of the same property name spelled the same way but with a "case" difference in the letters of the name. Because Windows Installer is case-sensitive, it treats these as two different properties.
- Errors. Report database authoring that cause incorrect behavior. For example, duplicate component GUIDs cause Windows Installer to incorrectly register components.
- Failures. Report the failure of the ICE custom action. Failure is commonly caused by a database with such severe problems that the ICE cannot even run.
Package Validation using Wise Package Studio
The below steps describe how to implement the process using WPS.
- Invoke the Package validation wizard from the side pane of Wise package studio as shown in Fig 1.
- Browse the .WSI or .MSI file on which the isolation has to be performed as shown in Fig 2.
- Choose on the validation checks. The next screens depend on the options selected here. This is shown in Fig 3.
The Package is being validated. Refer to Fig 4.
- The IC errors and details of this package is displayed in the following window. Refer Fig 5.
- Now, you can save the ICE report and check for its relevance in the desired environment.
Package Validation using ORCA
Orca.exe:
Orca tool is shipped with Windows Installer SDK. This tool allows the user to open a Windows Installer database as a database and examine or make changes to it.
Install Orca.msi with basic instructions on the machine.
- Edit the MSI package using Orca.(Right click on the MSI and choose option Edit with ORCA). When done a ORCA database explorer opens as shown in the figure 6.
- Go to Tools-> Validate (also can be invoked using Cntl+L ). This is shown in Fig no 7.
- In the validation Set dialog choose the Evaluation Criteria/File and mention the ICE's to be run on that particular package. This is shown in Fig no 8.
- When all the options are chosen click the button Go. This will start the validation process for this package. Refer Fig 9.
On Completion of Validation, all the ICE errors are displayed in a window as shown in Fig 10.
- You can copy all the ICE errors and Paste it in a excel sheet as shown in Fig 11.
Further, all the ICE errors are also displayed in the Orca tool. Refer Fig 12.
Now, we can check for the errors in the ICE report and resolve the same to suit our client environment.













Comments
Most Common ICEs found in re-packaged applications
1. ICE33 - If you repackage an installation with any version of Installshield AdminStudio, you will most certainly see ICE33. This ICE is caused by the fact that repackager adds COM related information into the registry table as supposed to the Microsoft recommended Class ID, Prog ID and Type Lib tables. This Error can be safely ignored as the application should work properly as your com information will be registered via the Registry table.
2. ICE64 - This ICE warns about directories created under the User Profile folder not being specified in the RemoveFile table. So for example if your msi package contains [AppDataFolder]mydir or [PersonalFolder]mysubfolder, ensure that ‘mydir’ & ‘mysubfolder’ are specified in the RemoveFile table. Doing so will ensure that they get removed at uninstallation time.
3. ICE57 - If you have a component in your msi package that contains both per-user & per-machine data e.g if the component is installing a file to [AppDataFolder] and also contains a registry key being installed under HKLM. you can expect to see this Error/Warning. The ideal thing to do is separate User data from machine data into separate components. Anytime you have a component that is installing to a User Profile directory, make sure that the component does not contain a key file. This component should instead have a key path. This component should contain a registry key under the HKCU hive, set as the key path. If your msi package does not contain any registry keys under HKCU hive, create a dummy key to ensure that your user profile data is installed properly for subsequent user logging on the machine.
4. ICE50 - This ICE usually occurs when your installation tool is unable to extract icon from the Icon file specified in the shortcut. Sometimes InstallShield Editor displays this error. The best way to work around it is to specify an Exe or different ico file in the shortcut to extract the icon from.
Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com
ICE 50 work around
You mention the work around is "to specify an Exe or different ico file in the shortcut to extract the icon from".
It would be very helpful if you could describe how to do the same.
(Newbie)
Thank you
Fix MSI Error 1615
Invalid ICE Number to APIErrorOut!
Evaluation: ICE??
ICE Internal Error 1001. API Returned: 1615.
or
Error 2229: , Directory, ALTER TABLE `Directory` ADD `_Profile` SHORT TEMPORARY HOLD
Evaluation: ICE90
ICE Internal Error 1001. API Returned: 1615.
Evaluation: ICE91
Error 2229: , Directory, ALTER TABLE `Directory` ADD `_Profile` SHORT TEMPORARY HOLD
Evaluation: ICE91
Some times wise validation throws strange error codes which is difficult to understand and fix, for example the "internal error 1000 API returned: 1615" there is no tips available in wise SDK for how to approach for fixing this problem or what might be causing this problem.
When this problems usually appears in the machine in which we are scripting, I think these problems are either because of the Wise tool is not able to validate properly, it is not able to use all the necessary components for validation, u can always fix this problem either by regoshting the machine and reinstall the wise tool. or take the MSI which is giving the problem and Validate in the different machine.
Microsoft MVP [Setup-Deploy]
Weblog: www.msigeek.com
Validation
Good Article
Would you like to reply?
Login or Register to post your comment.