我遇到了多字符串注册表搜索的问题，其中字符串搜索工作正常。 已签入安装日志
操作开始 13：40：07：应用搜索。微星 (40：E0) [13：40：07：381]： 属性更改：添加MYKEY 属性。其值为"。微星 (s) (40：E0)[13：40：07：381]：属性更改：添加我的服务属性。它的值是"myvalue2"。
我在这里修剪了一些日志
操作结束于 13：40：51： 计划重新启动。返回值 1。操作已结束 13：40：51：安装。返回 值 1。您必须重新启动系统才能进行配置更改 使XXXXX生效。单击"是"立即重新启动，或单击"否"(如果) 计划稍后手动重新启动。属性： 升级代码 = {XXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX属性： MYKEY = [~]myvalue1[~]属性： 我的服务 = 我的值2
在安装结束时，它似乎已正确评估 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="SYSTEMCurrentControlSetServicesMyService"
Name="mykey"
Type="raw" />
</Property>
<Property Id="MYSERVICE" Secure="yes">
<RegistrySearch Id="MYSERVICE"
Root="HKLM"
Key="SYSTEMCurrentControlSetServicesMyService"
Name="DisplayName"
Type="raw" />
</Property>
更新 ：我可能已经错过了您的说明，但是当仅使用 PROPERTYNAME 作为条件检查 AppSearch 设置的属性是否具有任何分配的值时，条件显示为 true - 这意味着相关属性中存在"某些东西"，只是不显示文本。
仅测试是否存在值就足够了，还是需要检查MYKEY的特定值？如果仅存在一个值就足够了，那么您可以使用以下条件：
((MsiNTProductType=1) OR (MYKEY) OR (MYSERVICE="MyService" AND MYKEY=""))
我想WiX用户邮件列表中的Rob Mensching的这个答案肯定地回答了这个问题。AppSearch 根本不支持多字符串。
没有必要怀疑这一点的准确性，因为Rob是最初的MSI团队的一员。您需要放弃这种方法。很抱歉说。除非我刚刚添加的上述解决方法可以工作(不检查值，而是检查是否有从注册表中检索的值)。
其他一些可能的解决方法：
- 您可以从自定义操作中读取多字符串。我刚刚验证了它是否适用于测试 VBScript - 禁止的 MSI 工具：-)。
- 您能否在磁盘上搜索一个文件或目录，该文件或目录表示与此多字符串从注册表中检索的内容相同？
正如我的座右铭时不时地说的那样：让我们沉迷于此(而不是：">小心，我们不想从中学习" - 这是我的另一个座右铭 - 这往往是更好的选择)。
真的很奇怪，我可以复制您对日志文件的陈述。我看到一个命令行条目，它正确地显示了多重刺痛，尽管有几个额外的空字符(略微缩短了日志条目)：
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
此外，在日志文件的后面，在安装完成之后：
Property(S): MULTISTRING = [~]String 1[~]String 2[~]String 3[~]
我真的不明白这是怎么来的。不知何故，AppSearch必须确实设置了有问题的属性，即使它看起来不像 - 该属性无法正确检索(或格式正确)，因此在(功能)条件下也无法工作？
也许Windows安装程序中的基础数据模型已将检索到的注册表多字符串值存储为BSTR(COM字符串格式的可憎之物，它允许嵌入空值，并且可以编译和链接，而无需通过SysAllocateString正确分配/构造 - ">烧伤的孩子，闻起来烧焦 - 以及所有这些......")。
无论如何，我想 AppSearch 需要一个常规的、以 null 结尾的字符串缓冲区，并这样解释BSTR？因此，偶然发现了第一个空值，它是 BSTR 数据字符串部分的第一个字符(不是长度前缀部分 - BSTR 指针将 4 个字节指向分配的 BSTR 内存)并报告整个空字符串？日志文件中显示的属性值一定是通过其他方式直接从基础数据模型中读取的吗？我会假设微星Win32 C++功能？但是，AppSearch不也是这种情况吗？此属性字符串(带有嵌入的 null)在条件中的显示和使用方式有问题。
所以总结一下：也许多字符串的检索实际上有效，但通过Session.Property("PROP")公开的值错误地将潜在的本机BSTR读取为以 null 结尾的字符串缓冲区，并将前导 null 解释为字符串缓冲区的末尾？考虑到Session.Property是一个 COM 调用并且绝对应该理解BSTR，这有点没有意义？像这样的理论从来都不正确，但也许它们至少可以帮助创造一些新的想法。似乎缺少Windows安装程序功能，我认为闻起来有点像错误。或者就像在现实世界中一样：一个技术问题，不容易解决，因此被视为并接受为缺失的功能。
让我将你关于这个问题的问题链接在一起以供参考(以及其他一些答案)：
- 多字符串类型的注册表值元素。
- 失败条件 wix。
- 通过命令行将多字符串值传递给安装程序。