ICE69
ICE69 checks that all substrings of the form [$componentkey] within a formatted string do not cross-reference components. A cross-component reference occurs when the [$componentkey] property of a formatted string refers to a component other than the component stored in the Component_ column of your tables.
Problems with cross-component referencing arise from the way formatted strings are evaluated. If the component referenced with the [$componentkey] property is already installed and is not being changed during the current installation (for example, being reinstalled, moved to source, and so forth), the expression [$componentkey] evaluates to null, because the action state of the component in [$componentkey] is null. Similar problems can occur during upgrade and repair operations.
Result
ICE69 returns an error if a [$componentkey] substring within a formatted string cross-references a component in another feature. ICE69 returns a warning if a [$componentkey] substring within a formatted string cross-references a component in the same feature. (The FeatureComponents table is used to determine this mapping. It must map to the same feature for the warning. Referencing components in parent features or referencing components in child features is considered to be an error.)
ICE69 reports an error if the [#FileKey] substring within a formatted string references a file which is not specified in the File table as belonging to the same component.
Example
ICE69 reports the following for the examples shown.
WARNING: "Mismatched component reference. Entry 'Test' of the Shortcut table belongs to component 'QuickTest'. However, the formatted string in column 'Argument' references component 'Test'. Components are in the same feature."
ERROR: "Mismatched component reference. Entry 'Shortcut2' of the Shortcut table belongs to component 'QuickTest'. However, the formatted string in column 'Argument' references component 'Test2'. Components are not in the same feature."
To fix this error, do not cross-reference components. Change the [$componentkey] to match the component of the shortcut.
Shortcut Table (partial)
| Shortcut | Component_ | Argument |
|---|---|---|
| Test | QuickTest | -v [$Test] |
| Shortcut2 | QuickTest | [$Test2] |
The Verb and Extension tables are special cases in that the Verb table references an extension that belongs to a component. An Extension, however, can belong to multiple components because the primary key for the extension table is made up of the Extension and Component_ columns. You can logically have the following situation.
Verb Table (partial)
| Extension | Verb_ | Argument |
|---|---|---|
| tst | open | -v [$comp1][$comp2] |
Extension Table (partial)
| Extension | Component_ |
|---|---|
| tst | comp1 |
| tst | comp2 |
| Feature_ | Component_ |
|---|---|
| Feature1 | QuickTest |
| Feature1 | Test |
| Feature2 | Test2 |
In this case, you must ensure that at least one of the [$componentkey] properties evaluates to a non-null value. However, every [$componentkey] property in the Argument column of the Verb table ([$comp1] and [$comp2] in the above example) must reference a possible component included with the extension associated with the verb. A reference like [$comp3] would result in a warning from ICE69.
The AppId table has a similar situation to the Verb table. It uses the Class table for its component reference. In this case, the AppId table is validated in the same way as the Verb-Extension validation (now AppId-Class).
The Class table's Argument column is validated like the Shortcut, Registry, and similar tables.
Table used during execution (only if found)
Related topics