Question

我面临着针对multistring的 RegistrySearch 的问题，其中字符串搜索工作正常。签入安装日志

行动开始13:40:07：AppSearch。 MSI（s）（40：E0）[13：40：07：381]：   PROPERTY CHANGE：添加 MYKEY属性。它的价值是＆＃39;。 MSI（s）   （40：E0）[13：40：07：381]：属性更改：添加MYSERVICE属性。   其值为“myvalue2＆＃39; 。

我在这里修剪了一些日志

行动结束13:40:51：   ScheduleReboot。返回值1.动作结束13:40:51：安装。返回   值1.您必须重新启动系统才能进行配置更改   使XXXXX生效。单击是立即重新启动，或单击否   计划稍后手动重启。物业（S）：UpgradeCode =   {XXXXXX-XXXX-XXX-XXXX-XXXXXXXX}   属性（S）：MYKEY = [〜] myvalue1 [〜] 属性（S）：MYSERVICE = myvalue2

在安装结束时，它似乎已经正确评估了MYKEY，但在AppSearch期间没有，导致我的条件评估失败

<Feature Id="MyFeature" Level="" Display="" Title="" Description="" AllowAdvertise="no" ConfigurableDirectory="INSTALLDIR">
   <MergeRef Id="MyFeature" Primary="yes"/>
   <Condition Level="0">((MsiNTProductType=1) OR 
   (MYKEY="[~]MyValue[~]") OR 
   (MYSERVICE="MyService" AND MYKEY=""))</Condition>
   </Condition>
</Feature>
<Property Id="MYKEY" Secure="yes">
        <RegistrySearch Id="MyKey"
                             Root="HKLM"
                             Key="SYSTEM\CurrentControlSet\Services\MyService"
                             Name="mykey"
                             Type="raw" />
</Property>
<Property Id="MYSERVICE" Secure="yes">
        <RegistrySearch Id="MYSERVICE"
                        Root="HKLM"
                             Key="SYSTEM\CurrentControlSet\Services\MyService"
                             Name="DisplayName"
                             Type="raw" />
</Property>

Answer 1

更新：我可能已经错过了您的陈述，但在检查AppSearch搜索设置的属性是否具有任何指定值时，只使用PROPERTYNAME作为条件，条件显示为true - 意味着所讨论的属性中存在“某事物”，文本不会显示。

仅测试值的存在是否足够，或者您是否需要检查MYKEY的具体值？如果只存在一个值就足够了，那么你可以使用这个条件：

((MsiNTProductType=1) OR (MYKEY) OR (MYSERVICE="MyService" AND MYKEY=""))

I guess this answer from Rob Mensching from the WiX-users mailing list answers the question with certainty。 AppSearch 根本不支持多字符串。

自从Rob加入原MSI团队以来，没有必要怀疑这种准确性。你需要放弃这种方法。很抱歉地说。除非我刚刚添加的上述解决方法可以工作（不检查值，但是如果从注册表中检索到任何值）。

其他一些潜在的解决方法：

您可以从自定义操作中读取多字符串。我刚刚验证它适用于测试VBScript - 禁用的MSI工具： - ）。
您是否可以在磁盘上搜索一个文件或目录，该文件或目录是否表示您使用此多字符串从注册表中检索的内容相同？

我的座右铭经常出现：让我们对这个着迷（而不是：“小心，我们不想从这个中学习” - 哪个我的另一个座右铭 - 往往是更好的选择。）

我真的很奇怪，我可以复制你对日志文件的陈述。我看到一个 CommandLine条目，它正确地显示了多个sting，虽然有几个额外的空字符（稍微缩短了日志条目）：

CommandLine: NORMALSTRING="sample regular string" MULTISTRING="[~~~]String 1[~~~]String 2[~~~]String 3[~~~]" INSTALLFOLDER="C:\Program Files (x86)\WiX3_GenericTestProject\" TARGETDIR="C:\" ACTION="INSTALL" EXECUTEACTION="INSTALL" ROOTDRIVE="C:\" INSTALLLEVEL="1" SECONDSEQUENCE="1"  ADDLOCAL=Empty,Modules,ProductFeature

以及稍后在日志文件中，在InstallFinalize之后：

Property(S): MULTISTRING = [~]String 1[~]String 2[~]String 3[~]

我真的不明白这是怎么发生的。不知怎的， AppSearch 必须真正设置有问题的属性，即使它看起来不像 - 属性无法正确检索（或格式正确），因此不起作用在（特征）条件下？

也许Windows Installer中的基础数据模型已将检索到的注册表多字符串值存储为 BSTR （COM字符串格式的憎恶，允许嵌入的空值并且可以编译和链接{{3 - “烧焦的孩子，闻到烧焦 - 以及所有...... ”）。

无论如何，我认为AppSearch会使用常规的，以null结尾的字符串缓冲区，并解释 without being properly allocated / constructed via SysAllocateString ？因此，第一个空值绊倒了，这是BSTR数据字符串部分的第一个字符（不是长度前缀部分 - BSTR）并报告整个空字符串？必须通过其他方式直接从基础数据模型中读取日志文件中显示的属性值吗？我会假设MSI Win32 C ++函数？但AppSearch也不是这样吗？ 如何在条件 中显示和使用此属性字符串（包含嵌入的空值）时出现问题。

总结一下：也许多字符串的检索实际上有效，但是通过Session.Property("PROP")的暴露值错误地将潜在的本机 BSTR 读作空终止字符串缓冲区并解释前导null作为字符串缓冲区的结尾？考虑到Session.Property是一个COM调用并且肯定应该理解 BSTR ，排序是没有意义的？像这样的理论永远不会是正确的，但也许它们至少可以帮助创造一些新的想法。看起来像是一个缺少的Windows Installer功能，有点像我想的臭虫。或者在现实世界中：技术问题，不易修复，因此被视为缺失特征。

让我将您对这个问题的问题联系起来以供参考（以及其他几个答案）：

WiX RegistrySearch的MultiString失败了

1 个答案: