我收到 ICE03：以下代码的字符串溢出警告：
<CustomAction Id="CustomActionID"
Return="check"
Property="SomeProperty"
Value="VERY LONG STRING COMES HERE"
Execute="immediate"/>
此代码包含在片段中的单独 .wxs 文件中。如果我将它直接包含在“产品”标签中，那么警告就会消失。以下代码也会发生这种情况：
<Binary Id="SomeBinaryWithAVeryLongName" SourceFile="SOURCEFILE" />
我想知道为什么会这样？
【问题讨论】：
CustomAction/@Value 属性在 Windows 安装程序中的字符数限制为 255 个。因此，如果您的 "VERY LONG STRING COMES HERE" 包含超过 255 个字符，您将遇到 ICE 警告。 Binary/@Id 甚至更短，因为它们是 MSI 中的“标识符”，而 Windows Installer 标准化了这些标识符的 72 个字符。
为什么 ICE03warning 消息放在 Product 元素下时会有所不同，这是一个谜，因为 ICE 验证是针对最终 MSI 执行的。最终的 MSI 并不关心您如何组织 .wxs 源代码来构建 MSI。根据代码是在Product 中还是在Fragment 下，您是否有可能看到其他警告（不是 ICE03）？
我之所以询问Product 或Fragment 之间的区别是因为编译器在编译Product 部分和Fragment 部分时知道不同的东西。编译器知道Product 部分将创建一个.MSI 文件。另一方面，Fragment 可以创建 .MSI 文件、.MSM 文件或 .MSP 文件。除了 .MSI 文件之外，.MSM 和 .MSP 文件还有其他限制。
例如，在构建 .MSM 文件时，所有标识符都以Module/@Id 为后缀。这为已经限制为 72 个字符的标识符增加了 37 个字符。 Binary/@Id 受到进一步限制，因为它最终成为 .MSM 文件中流的名称，因此不能超过 60 个字符。
无论如何，最终结果是当在Fragment 中时，编译器会将所有可能的规则应用于标识符。在所有情况下，这些规则可能比绝对必要的限制性稍强。但是，如果您注意所有警告/错误，那么您的代码应该在所有情况下都可以编译。
【讨论】：