Windows Installer
Unrestricted access to Windows Installer functionality!
Open Source
Open source!


Plain XML based source scripts!
Free, no strings attached!
Build Automation
Command-line interface for automated application build process!
Thriving community support!
Why WiX?

What does ICE33 check?

ICE33 validates that the all the entries in the Registry table belong in that table.

Even though Registry table is used to create/edit registry keys on the target machine, it is not the only table used to do this task. Registry keys that register Classes, Filename Extensions, ProgIDs, Shell Verbs, Remote Server AppIDs, MIME types, or Typelibs are considered as special keys because they can be used as advertised entry points to the application. Maximizing the number of advertised entry points to the application increases the chances that the application can trigger self-repair in a situation where the application is expected to fail. Technically entering these special registry keys to Registry table does not create any problems as far as the application functionalities and the setup are concerned. These special keys will still be registered by means of Registry table. However, Windows Installer service will not consider these keys as advertised entry points to the application. Hence, they will not be able to trigger self-repair if needed. Use of Extension, ProgId, Verb, MIME, Class, Typelib and AppId tables provides the extra benefit by maximizing your potential for self-healing.

The other disadvantage of keeping ICE33 warnings in your MSI package is the fact that you will not be able to fully advertise your product if you want to utilize advertising features of Windows Installer. That means, installation-on-demand will be limited to only advertised shortcuts but not other entry points such as file extensions or MIME types. That is because advertising simply puts down the advertised entry points to the target machine and postpones the rest of the installation to a time that the application is somehow triggered by an advertised entry point. If Registry table is used to store those entry points such as file extensions, they will not show up during advertisement. They will only show up when the application is fully installed.

When does ICE33 show up?

ICE33 issues a warning for each Registry table entry that should be moved and suggests the appropriate table. ICE33 posts warnings for any entries that register Classes, Filename Extensions, ProgIDs, Shell Verbs, Remote Server AppIDs, MIME types, or Typelibs.

How can I fix ICE33?

The fix is to move those special registry entries to the table(s) suggested by the warning. However, unless you are very familiar with registry as well as the application, it is not recommended to move them especially in a repackaging situation. Taking such an action without much familiarity with registry and the application can cause more problems with your MSI package.

Extensions, ProgIds, Verbs, and MIME types must be registered through their respective Extension, ProgId, Verb, MIME tables to support advertisement and install-on-demand. Entries in the Registry table are not written to the registry until the component controlling the value is installed to run Locally or to Run From Source. This precludes the advertisement of components registered through the Registry table. It also precludes install-on-demand for any feature or product requiring the component because advertisement is the only way install-on-demand is available through the Windows Shell.

For Windows 2000, COM Classes must be registered through the Class table to advertise CLSID Contexts and for install-on-demand.

Note that the tables available cannot handle all possible COM registration. In these cases an author should enter as much information as possible into to the individual tables and the remaining information into the Registry table. A common authoring error that must be avoided in this case is that of duplicating an entry in both a COM table and in the Registry table.

It is easier to manage registry keys if they are listed in the appropriate tables rather than being mixed together into the Registry tables. The values in the Typelib and AppId tables are registered when the component controlling the value is installed to run Locally or From Source. These tables are provided for the convenience of setup authors.