【发布时间】:2015-05-29 17:40:06
【问题描述】:
很少有人尝试回答有关 CustomActionData 的 ICE03(字符串溢出)的问题,但我似乎无法确定/得出如何解决此问题的正确(或可接受的)做法。
我目前的解决方案是通过保持键名和属性名的简短来减少键值对的长度,即来自:
<CustomAction Id="MyCustomActionData"
Property="MyCustomActionCA"
Value="myKeyName1=[SOME_PROPERTY_NAME];myKeyName2=[SOME_DESCRIPTIVE_PROPNAME]"/>
到:
<CustomAction Id="MyCustomActionData"
Property="MyCustomActionCA"
Value="k1=[K1];k2=[K2]"/>
但我觉得我只是将问题扫在地毯下,迟早我会再次遇到(另外,这是基于我下面的附加问题的假设)。
更明显的解决方案是重新评估和重新设计它,以便将最少的数据量传递给 C# CustomAction(经典的“为什么要声明一个函数方法来传递 20 个参数? “所有代码审查员的问题)。显然,对于今天的大多数语言,我们可以轻松地重新设计 API 并传递一个自包含所需内容的对象(作为类、结构等 - 取决于语言),但是如何处理进程间调用(我见过带有相当大数据的 JSON RPC 消息,我通常想知道这是否是因为有人试图通过添加越来越多直到它变得臃肿而不是坐下来重新设计来修复一些遗留代码,这不是可能在某个“第 11 小时”的最后期限内,只需在允许的最短时间内修复)。
也许解决方案是创建一个 XML 文件并在调用 CustomAction 之前使用 expat ('util:XmlFile') 搜索和替换键值对,并将更改后的 XML 的文件名作为 CustomActionData 传递给 CustomAction 使用,然后在 C# CustomAction 代码中,它只是反序列化它并将其视为对象。但这也感觉有点笨拙(它也可能让下一个未来接手我任务的开发人员感到困惑),更不用说如果它是密码,我们不想将它放在 XML 文件中并将其保留为属性隐藏=“是”...
所以我的问题是,解决传递可能超出表列大小的 CustomActionData 的问题的干净/优雅的解决方案或模式(或做法)是什么?
如果我还可能问一个有点相关的附加问题,我假设链接器(灯)警告 LGHT1076 是基于值的长度(即“keyA=[A];keyB=[B]” ) 太长,因此如果我选择非常短的属性变量和键名,它很可能不会触发此警告。但据我了解,表列大小为 255 个字符(如果我错了请纠正我)因此在运行时,如果属性值长于列大小,可能会导致一些问题(或被截断)?
【问题讨论】:
标签: wix custom-action