Software Deployment

http://msdn.microsoft.com/en-us/library/aa369206%28VS.85%29.aspx

You can click on each ICE for a description. You can also Google or search Appdeploy for an ICE error to learn more practical information.

ICE errors should be fixed, but ICE warnings can be ignored in some cases. Worry most about the errors, as these are likely to make your MSI tank on install.

Sorry to hear about your predicament. If you search for an ICE error and can't find any info, please post the details here and we'll give you a hand. You'll find ICEs will make much more sense when you understand the MSI database in general.

Here's a beginner Wise guide (it's a bit old, but so is Wise). It talks about ICE as well.
http://www.dawnstar.com.au/wpshelp/dl/WPS%20for%20Newbies%20Tutorial_mar04.pdf

Bear in mind that errors in vendor MSIs really aren't worth troubling yourself with and also that, in many cases, fixing one error produces another.

Many thanks.....
I understand that only Errors should be fixed, I have the list of errors and how they can be fixed, but to be honest it all seems like double dutch.
I'll have a read about the MSI Database and post up an error for a package if someone could take me through the process of removing the error step by step that would be great... simply trying to follow the "how to remove the error" does not really help me.
Really sorry to impose on people for whom this must be really basic stuff..

Hi Dogsbody,

I am very happy to share this link to you. I had used this link for so long and hope to help you and other newbies out there with the Step by Step procedures in Wise packaging starting from creating your rig down to fixing your ICE errors and other trips and tricks.

Check it out! http://www.dawnstar.com.au/wpshelp/welcome.html

Superb document....
i'll work through that over the weekend... hopefully it will put me on the right path..

thanks again for the help... I hope one day to be able to feedback some help too...

Here is an outline of some common ICE errors I encounter, 03, 19, 33, 38, 57, 64, 69 and 91. No-nonsense descriptions and my best practice recommendation.

Hope this helps all!



Common ICE Errors Encountered in Repackaged Applications

ICE03
SDK Description:
ICE03 validates data types and foreign keys based on the _Validation table. Detailed Description:
The Windows Installer database has pre-defined datatypes describing the format of GUID’s, file names, registry entries, etc. The ICE03 validation ensures that field fit the format defined in the SDK.
Additionally, the _Validation table contains information on the exact columns that subsequent tables should contain and whether or not columns in those tables must contain information.
Common Errors
There are times that applications will create registry keys that do not conform to the Windows Installer defined format. An example is Adobe Reader 5.05. This installation creates a two registry keys that have an open curly bracket “{“ but no trailing bracket. This format does not comply with RegPath as defined in the SDK.
Adobe Reader 7.0.5 has entries in the directory table that do not conform to the ShortFileName format. Directory names have short file names that are greater than 8 characters.
Best Practices Recommendations
The ICE error can be resolved by adding the ending curly brackets to the registry key. Important: This is not recommended. As a repackaged application, you will not know if the package actually reads the registry key in the “incorrect” format.
In the case of short file names, you must use a transform to correct the issue or you will not be able to run an administrative install that installs the files and directories with short file names.
How the Windows Shell uses Extensions, Program ID’s, Verbs, MIME types, and Class ID’s.
The ability to double click on a file in Windows Explorer and have it launch an application is a process called Extending the Windows Shell.[/align]

When an application associates an extension with a program, it begins by adding that extension to the HKEY_CLASSES_ROOT key. The extensions default value is the Program ID of the application. The Program ID contains a reference to the Class ID, which in turn contains an entry to the InProcServer or LocalServer which is the path to the program that handles the file extension.
The Windows Shell also allows applications to use context menus, i.e. right click on a .txt file, to give users options on what to do with the file. The most common types of actions are open, print and play. These are implemented in the registry through the use of Verb entries defined under the CLSID key for the application.
Windows Installer makes use of these registry keys to install advertised applications and repair applications that contain “broken” components. A number of ICE validation tests confirm that these keys have the proper relationships to insure Windows Installer has the information it needs to properly install / repair an application.

ICE19
SDK Description:
ICE19 validates that advertised components reference a file in the KeyPath column of the Component table and that an advertised shortcut references a directory in this column.
Detailed Description:
If this error occurs you will find that one of the advertising registry tables (Extensions or Class) points to a component that does not have a file that is the KeyPath entry. It is important to remember that Windows Installer uses the advertising keys to repair applications. If the advertising entry points to a component that does not contain files for installation / repair it is not truly advertising information and should be entered into the Registry table. See How Windows Shell Uses Extension for further information.
Common Errors
During the capture of the Adobe Reader 5.0.5 two extensions .api and .dgi are captured and type point to the ProgID of AcroExch.Plugin. The issue being that the ProgID does not point to a CLSID. If an application attempts to access a file with either extension, Windows Installer will not be able to install advertised components or repair missing components because there is no file defined as the destination for the extension.
Best Practices Recommendations
It is recommended that these extensions be removed from the File Associations page and the registry entries added directly to the registry. It is important to note that this recommendation will cause and ICE33 error to be generated.[/align]

ICE33
SDK Description:
ICE33 validates that the all the entries in the Registry table belong in that table. Detailed Description:
This is one of the most common validation errors when repackaging applications. It will be dramatically worse, if during Setup Capture you select to Retain Registry Entries. See How Windows Shell uses Extensions for further information.
Windows Installer uses the information in the Extensions, CLSID, Verbs, ProgID, and MIME tables to install registry entries that will be used later to install advertised applications and to repair applications with missing components. The ICE33 error identifies entries that the Windows Installer package have added to the Registry table, that it feels should be added to one of the appropriate Advertising (Class, Extension, ProgID, MIME, or Verb) tables.
Common Errors
As described in the ICE1 9 error, the solution to the error was to move the information from the Extension table to the Registry table. While this addresses the ICE1 9 error, it causes an ICE33 error.
An additional error occurs in the Adobe Reader 5.0.5 package for the registry key CLSID\ {DF9A1DA0-23C0-101B-B02E-FDFDFDFDFDFD}, which is installed into the registry table. The Windows Installer Validation tool identifies that the registry entry is a CLSID entry which should be installed to the Class table. The Setup Capture program identified that there was no InProcServer key, which could be used to install advertised components or repair broken components. The Windows Installer validation tool does not have the ability to identify the subkeys which should contain information needed to determine whether or not there is sufficient information to install the appropriate components.
Best Practices Recommendations
As these are just warning entries, it can be very difficult to solve or remove these errors in a repackaging environment. Due to the fact that the validation tools cannot analyze subkeys many of the entries that fall into this category cannot be addressed. ICE33 errors should therefore be reviewed, but very seldom be addressed.

ICE38[/align]
ICE38 validates that every component being installed under the current user's profile also specifies a registry key under the HKEY_CURRENT_USER root in the KeyPath column of the Components Table.
Detailed Description:
Windows Installer specifies that any file components that are installed to the users profile have a keypath that points to a HKCU key. This makes the advertising / repair process more efficient.
This error is actually created by using the default Component Rules defined in the Windows Installer Editor. If there are no registry keys that are directly associated with a file that is installed to the user profile, all HKCU registry entries are added to their own component.
Common Errors
As described, this will happen any time there is a file that is installed to the user profile that does not have a registry key directly related to that file.
Best Practices Recommendations
Move a registry key from the CurrentUser component to the identified component. You will then need to update the component to use the newly added registry key to be the keypath for the component.

ICE57
SDK Description:
ICE57 validates that individual components do not mix per-machine and per-user data. This ICE custom action checks registry entries, files, directory key paths, and non-advertised shortcuts.
Detailed Description:
This error occurs when registry entries point to files that are installed to any folder other than a current user profile folder. Based on the Microsoft Best Practices component rules, registry keys that have associated files are placed in the same component. This sets up a scenario where there is a registry key that is installed to the HKCU key that references a file that is not installed to the user profile.[/align]

Adobe Reader 5.0.5 has Netscape Navigator keys that are installed to the HKCU key that reference the AcroRd32.exe file that is installed to the Program Files folder. If you have selected to use the Microsoft Best Practices component rules, these keys will be added to the same component as AcroRd32.exe.
Best Practices Recommendations
Best Practices dictate that you change the Microsoft Best Practices rules to move the rule to place all HKCU keys into the same component to be run prior to the rule to associate registry keys with their corresponding files. This is recommended because in a repackaging environment, it is very seldom that software be installed as advertised components.
In the Common Errors example the keypath is the file AcroRd32.exe, which means that if that file is erroneously removed from the machine, Windows Installer will reinstall the component, which is a desired result. It is important to remember is that if a second user attempts to use the application (assuming a Per Machine installation), the HKCU registry keys will not be installed for that user. In the example, AcroRd32.exe will be on the machine, and since it is the current keypath file, Windows Installer will not self heal, meaning the HKCU registry keys for this component will not be installed for the user.
It is important to note that if Best Practices are followed, ICE69 errors will be created.

ICE64
SDK Description:
ICE64 checks that new directories in the user profile are removed correctly in roaming scenarios.
Detailed Description:
This error pertains to roaming profiles. Since the profile exists on both the computer that the user is currently accessing, and on a file server that is used to supply profiles as the user moves from computer to computer. Each time a user moves to a computer that thy have not accessed previously their profile will be copied to that machine.
Windows Installer will only uninstall folders that were not present when the application was installed. Since the roaming profile is downloaded prior to Windows Installer testing for application health, Windows Installer assumes that any folders that are currently on the machine existed prior to the installation and therefore will not remove the folders when the application is removed from the system.
Common Errors
This error will occur for any application that creates directories in the user profile.[/align]
Best Practices Recommendations
If your site has roaming profiles add the created folders to the RemoveFiles table as describe in the Windows Installer SDK.

ICE69
SDK Description:
ICE69 checks that all substrings of the form [$componentkey] within a formatted string do not cross-reference components. Note: This error will be created if using the Best Practices resolution for ICE57 errors.
Detailed Description:
If a registry key refers to a component other than its component, this error will be generated. Windows Installer generates this error because it is possible for different components to have different installation states. The syntax [$componentkey] refers to the action state, or “what is going to happen to this component during this Windows Installer installation.” It is possible that the component being reference will not be installed during this Windows Installer session and therefore the [$componentkey] will not evaluate to the correct condition.
Common Errors
This error will occur if you correct an ICE57 error. Best Practices Recommendations
It is uncommon that repackaged applications are advertised. Since repackaged applications are not advertised, the error described in the detailed description will not occur. These errors can be ignored if you are installing all components that the user would need during the initial installation.

ICE91
SDK Description:
ICE9 1 posts a warning if a file, .ini file, or shortcut file is installed into a per-user only directory. These warnings are harmless if the package is only used for per-user installations and never used for per-machine installations.
Detailed Description:
This is truly a “warning” explaining to you that you are going to be placing files in folders that are user specific.[/align]
It is important to remember that if you do in fact install the application with ALLUSERS=1 or per-machine that all advertising information will be available to all users who access the system. Any user other than the user that installed the application originally will not have any of the files or registry entries that were installed during the initial installation. Windows Installer will repair those components that have not been correctly installed for each additional user assuming it has access to the source installation files.
Common Errors
This error will occur for any application that installs files to a user profile folder. Best Practices Recommendations
This warning can safely be ignored.

ice 33 u can ignore, if ur projects agrees...or if you want your client's workstation's object registration to be broken.

If you leave registry entries in the Registry table which ought to be in the so-called advertising tables (which is what ICE33 is highlighting), they will obviously be removed when the product is uninstalled, thus obliterating registration information for objects. This will most likely make you less than popular.

Agreed.. you should at least remove the registry entries that are being written by the proper tables.

Any ICE33's that are left should be written by the correct component and not the ususal 'catch all' component that Wise dumps everything into that it doesn't know what to do with. These are the ones that can cause you pain when you uninstall your dodgy package...

Cheers,
Rob.

hi guys on the subject of ice 33's (warning's) are we talking destkop msi packaging or citrix msi packaging
regarding citrix msi packaging should we not have all our advertising info in the registry table rather than the com tables ie not to trigger any kind of self repair

and as per microsoft windows installer best practises are we not supposed to rather not put info in the proid table and leave stuff in the registry table

I am open to all your comments

Windows installer best practises says that, dll, or ocx registration should be done through com registration. Please correct me if i am wrong...

ORIGINAL: VBScab

ice 33 u can ignore, if ur projects agrees...or if you want your client's workstation's object registration to be broken.

If you leave registry entries in the Registry table which ought to be in the so-called advertising tables (which is what ICE33 is highlighting), they will obviously be removed when the product is uninstalled, thus obliterating registration information for objects. This will most likely make you less than popular.



Microsoft doesn't think so...

Direct quote from MSDN:

ICE33 processes entries in the Registry table and may issue a warning for each table entry that registers Classes, Filename Extensions, ProgIDs, Shell Verbs, Remote Server AppIDs, MIME types, or Typelibs. The warnings are obsolete and can be ignored.

http://msdn.microsoft.com/en-us/library/aa368957(VS.85).aspx

the com tables give your msi the options of advertising and self repair

but you really don't want to put com info in the advertising tables when creating an msi for citrix servers

http://msdn.microsoft.com/en-us/library/bb204770(VS.85).aspx

The warnings are obsolete and can be ignoredSo...my package contains this entry in the Registry table (extreme example, to make the point):

"registry","0","CLSID\{00000303-0000-0000-C000-000000000046}\","InprocServer32","ole32.dll","PleaseBreakMe"

Happy to have this removed on uninstall? Please: look at the quality of questions here first and ask yourself if posts on reference-counting, conflict management, etc. are relevant for now before embarking on one.

Bottom line? Don't use self-registration or RegSvr32. Do it properly.

Thanks VBS, after reading your posts on this thread and the one next door, I think I'm finally starting to see the light. I just read through the Windows Installer Best Practices page, specifically the portion titled "do not use the SelfReg and TypeLib tables".

Let me sum up what I believe to be correct, and then ask a question. According to best practice:
1) You should never use the SelfReg table, the Registry table should be used instead.
2) You should never use the TypeLib table, the Registry table should be used instead.

Now for my question. Earlier you had stated:
If you leave registry entries in the Registry table which ought to be in the so-called advertising tables (which is what ICE33 is highlighting), they will obviously be removed when the product is uninstalled, thus obliterating registration information for objects.
It's my understanding that any entries that are put down via the registry table will be removed on uninstall (unless the component is otherwise modified to leave them). Forgive me if this sounds noobish, but which entries ought to be in the so called advertising tables, and why? Also, what are the exact names of these so called advertising tables?

This is the main reason that I recently started posting up is for threads like this, I wanted to make sure that I keep my packaging skills sharp and best practice. As one of 2 packagers at the place I work, rarely does our work ever get questioned and I want to make sure everything is done properly, and chat with the best! Thanks for all the replies.

Forgive me if this sounds noobish, but which entries ought to be in the so called advertising tables, and why? Also, what are the exact names of these so called advertising tables?

the tables are class,progid,typelib ,registry

read all about ice 33 on this website and I am sure you will understand more

http://installworld.com/index.php?view=article&catid=42%3Aice&id=203%3Aice33&option=com_content&Itemid=138

...not forgetting AppID, Extension, MIME and Verb.