ICE03: String overflow (greater than length permitted in column); Table: CustomAction

Question

I am getting an ICE03: String overflow warning for the following code:

<CustomAction Id="CustomActionID"
          Return="check"
          Property="SomeProperty"
          Value="VERY LONG STRING COMES HERE"
          Execute="immediate"/>

This code is included in a separate .wxs file in a fragment. If I include this directly within the "Product" tag then the warning disappears. This also happens with the following code:

<Binary Id="SomeBinaryWithAVeryLongName" SourceFile="SOURCEFILE" />

I would like to find out why is this happening?

Answer 1

The CustomAction/@Value attribute has a limit of 255 characters in the Windows Installer. So, if your "VERY LONG STRING COMES HERE" has more than 255 characters you will be hitting that ICE warning. Binary/@Id are even shorter because they are "identifiers" in the MSI and the Windows Installer standardized on 72 characters for those identifiers.

It is a mystery as to why the ICE03warning message would be different when placed under a Product element because the ICE validation is executed against the final MSI. The final MSI does not care how you organized your .wxs source code to build the MSI. Is it possible you are seeing other warnings (not ICE03) based on whether the code is in the Product or under a Fragment?

The reason I ask about the difference between Product or Fragment is because the compiler knows different things when it is compiling a Product section vs. a Fragment section. The compiler knows that a Product section will be creating an .MSI file. A Fragment on the other hand could be creating an .MSI file, a .MSM file, or a .MSP file. The .MSM and .MSP files have additional restrictions beyond a .MSI file.

For example, when building a .MSM file all of the identifiers are suffixed with the Module/@Id. That adds an additional 37 characters to the identifiers which are already limited to 72 characters. The Binary/@Id is further limited because it ends up being the name of the stream in the .MSM file and thus can't go over something around 60 chars.

Anyway, the net result is that when in a Fragment the compiler applies all the possible rules to the identifiers. The rules may be slightly more restrictive than absolutely necessary in all cases. However if you heed all the warnings/errors then your code should compile in all cases.