对于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(经典&#34;为什么要声明一个函数方法通过20个参数?&#34;所有代码评审员的问题)。显然,对于今天的大多数语言,我们可以轻松地重新设计API并传递一个自包含所需内容的对象(作为类,结构等 - 依赖于语言),但是如何进行进程间调用呢? (我已经看到JSON RPC消息带有相当大的数据,而且我常常想知道是不是因为有人试图通过添加越来越多来修复一些遗留代码,直到它变得臃肿而不是坐下来重新设计,这在某些&#34; 11小时&#34;截止日期是不可能的,只需要在最短的时间内得到修复)。
也许解决方案是创建一个XML文件并使用expat(&#39; util:XmlFile&#39;)在调用CustomAction之前搜索和替换键值对,并将更改后的XML的文件名作为要使用CustomAction的CustomActionData,然后在C#CustomAction代码中,它只是反序列化它并将其视为对象。但是这也感觉有点笨拙(它可能会混淆将来接管我任务的下一个开发人员),更不用说它是否是我们想要不在XML文件中保存的密码并将其保留为隐藏的属性=&#34;是&#34; ...
所以我的问题是,有什么干净/优雅的解决方案或模式(或实践)来解决传递可能超出表列大小的CustomActionData的问题?
如果我还可以提出一个有些相关的附加问题,我假设链接器(灯)警告LGHT1076是基于值的长度(即&#34; keyA = [A]; keyB = [ B]&#34;)太长了,所以如果我选择了非常短的属性变量和键名,它很可能不会触发这个警告。但据我所知,表列大小为255个字符(如果我错了,请纠正我)因此在运行期间,如果属性值比列大小长,则可能导致某些问题(或截断) ?
答案 0 :(得分:2)
我使用的解决方案是创建多个属性,然后将这些属性最终连接成一个属性,这样:
<CustomAction Id="SetSqlProperties"
Property="SqlProperties"
Value="SQL_LOGIN_ID=[SQL_LOGIN_ID];SQL_PASSWORD=[SQL_PASSWORD];
SQL_AUTH_TYPE=[SQL_AUTH_TYPE];SQL_SERVERS=[SQL_SERVERS]" />
<CustomAction Id="SetServerProperties"
Property="ServerProperties"
Value="Domain=[DOMAIN];ComputerName=[COMPUTER_NAME];
FullServerName=[FULLCOMPUTERNAME];Version=[ProductVersion];
ServerType=[SERVER_TYPE];SrvMode=[SrvMode]" />
<CustomAction Id="SetPropertiesConfigReplace"
Property="ConfigReplace"
Value="InstallFolder=[INSTALLFOLDER];[ServerProperties];[SqlProperties]" />
在此示例中,我将使用包含SQL Server和本地服务器中所有值的属性[ConfigReplace]
。
关于ICE03,您可以在文档中找到:
字符串的长度大于列定义指定的列宽。请注意,安装程序不会在内部将列宽限制为指定值。见Column Definition Format。 MSDN