WiX RegistrySearch 对 MultiString 失败 [英] WiX RegistrySearch is failing for MultiString
问题描述
我遇到了 RegistrySearch 的多字符串问题，因为字符串搜索工作正常.检查安装日志
I am facing issue for RegistrySearch for multistring, where as string search working fine. Checked in installation logs
行动开始 13:40:07:AppSearch.MSI (s) (40:E0) [13:40:07:381]:属性更改:添加 MYKEY 属性.其值为''. MSI (s)(40:E0) [13:40:07:381]:属性更改:添加 MYSERVICE 属性.其值为myvalue2".
Action start 13:40:07: AppSearch. MSI (s) (40:E0) [13:40:07:381]: PROPERTY CHANGE: Adding MYKEY property. Its value is ''. MSI (s) (40:E0) [13:40:07:381]: PROPERTY CHANGE: Adding MYSERVICE property. Its value is 'myvalue2'.
我在这里修剪了一些原木
I have trimmed some logs here
行动于 13:40:51 结束:计划重启.返回值 1.操作结束 13:40:51:安装.返回值 1. 您必须重新启动系统才能更改配置使XXXXX生效.单击是"立即重新启动，否则单击否"计划稍后手动重启.属性(S):升级代码 ={XXXXXX-XXXX-XXX-XXXX-XXXXXXXX}属性(S):MYKEY = [~]myvalue1[~] 属性(S):MYSERVICE = myvalue2
Action ended 13:40:51: ScheduleReboot. Return value 1. Action ended 13:40:51: INSTALL. Return value 1. You must restart your system for the configuration changes made to XXXXX to take effect. Click Yes to restart now or No if you plan to manually restart later. Property(S): UpgradeCode = {XXXXXX-XXXX-XXX-XXXX-XXXXXXXX} Property(S): MYKEY = [~]myvalue1[~] Property(S): MYSERVICE = myvalue2
在安装结束时，它似乎已正确评估 MYKEY，但在 AppSearch 期间未正确评估，导致我的条件评估失败
At end of installation it seems it has correctly evaluated the MYKEY but not during AppSearch, resulting in failing my Condition evaluation
<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>
推荐答案
UPDATE: 我可能已经错过了你的陈述，但是在检查属性是否由AppSearch 搜索具有任何分配的值，仅使用 PROPERTYNAME 作为条件，条件显示为真 - 意味着某物"存在于相关属性中，只是不显示文本.
UPDATE: I might have missed you stating it already, but when checking whether the property set by the AppSearch search has any assigned value at all using simply PROPERTYNAME as condition, the condition shows up as true - meaning that "something" exists in the property in question, the text is just not displayed.
仅仅测试一个值是否足够，还是需要检查MYKEY的具体值?如果仅仅存在一个值就足够了，那么您可以使用这个条件:
Is it sufficient to test just for the presence of a value, or do you need to check the specific value of MYKEY? If the mere presence of a value is enough, then you may be able to use this condition:
((MsiNTProductType=1) OR (MYKEY) OR (MYSERVICE="MyService" AND MYKEY=""))
我猜这个来自 WiX 用户邮件列表的 Rob Mensching 的回答肯定地回答了这个问题.AppSearch 根本不支持多字符串.
没有必要怀疑这一点的准确性，因为 Rob 在最初的 MSI 团队中.你需要放弃这种方法.不好意思说.除非我刚刚添加的上述解决方法可行(不是检查值，而是检查是否有从注册表中检索到的值).
There is no need to doubt the accuracy of this since Rob was on the original MSI team. You need to abandon this approach. Sorry to say. Unless the above workaround that I just added could work (check not the value, but if there is a value at all being retrieved from the registry).
其他一些潜在的解决方法:
A couple of other, potential workarounds:
- 您可以从自定义操作中读取多字符串.我刚刚验证了它可以与测试 VBScript 一起使用 - 禁止使用的 MSI 工具 :-).
- 您能否在磁盘上搜索一个文件或目录，该文件或目录与您使用此多字符串从注册表中检索到的内容相同?
<小时>
正如我的座右铭那样:让我们专注于此(而不是:小心，我们不想从中学习"-是我的另一个座右铭 - 这往往是更好的选择).
As my motto goes every now and then: let's obsess over this (as opposed to: "careful, we don't want to learn from this" - which is another motto of mine - which tends to be the better option).
我可以复制您对日志文件的陈述，这真的很奇怪.我看到一个 CommandLine 条目，它正确显示了多刺，尽管有几个额外的空字符(稍微缩短了日志条目):
It is truly odd, that I can replicate what you state about your log file. I see a CommandLine entry which shows the multi-sting correctly, albeit with several extra null characters (slightly shortened log entry):
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 之后:
and also, later in the log file, after InstallFinalize:
Property(S): MULTISTRING = [~]String 1[~]String 2[~]String 3[~]
我真的不明白这是怎么回事.不知何故，AppSearch 必须确实设置了有问题的属性，即使它看起来不像 - 该属性无法正确检索(或格式正确)，因此不起作用在(功能)条件中?
I really don't understand how that comes about. Somehow the AppSearch must have really set the property in question even if it didn't look like it did - the property just can't be retrieved correctly (or formatted correctly), and hence doesn't work in (feature) conditions either?
也许 Windows Installer 中的底层数据模型已将检索到的注册表多字符串值存储为 BSTR(COM 字符串格式的可恶之处，它允许嵌入空值并且可以编译和链接 没有通过 SysAllocateString 正确分配/构造 - 烧焦的孩子，闻起来有烧焦的味道 - 以及所有这些......").
Maybe the underlying data model in Windows Installer has stored the retrieved registry multi string value as a BSTR (the abomination of a COM string format which allows embedded nulls and can be compiled and linked without being properly allocated / constructed via SysAllocateString - "burnt child, smells burnt - and all that...").
无论如何，我想 AppSearch 需要一个常规的、以空字符结尾的字符串缓冲区并解释 BSTR 这样?因此绊倒了第一个空值，它是 BSTR 数据字符串部分的第一个字符(不是长度前缀部分 - BSTR 指针指向分配的 BSTR 内存的 4 个字节) 并报告一个空字符串?日志文件中显示的属性值一定是通过其他方式直接从底层数据模型中读取的吗?我会假设 MSI Win32 C++ 函数吗?但是，对于 AppSearch 来说，情况不也是如此吗?此属性字符串(带有嵌入的空值)在条件中的显示和使用方式存在问题.
Anyway, I suppose AppSearch expectes a regular, null-terminated string buffer and interprets the BSTR as such? Hence stumbling on the first null value which is the first character of the data string section of the BSTR (not the length prefix section - the BSTR pointer points 4 bytes into the allocated BSTR memory) and reports an empty string overall? The property values that show up in the log file must have been read directly from the underlying data model by other means? I would assume the MSI Win32 C++ functions? But wouldn't that also be the case for AppSearch? Something is wrong with how this property string - with embedded nulls - is being displayed and used in conditions.
总之:也许多字符串的检索确实有效，但是通过Session.Property("PROP")公开的值错误地读取了潜在的、原生的BSTR 作为以空字符结尾的字符串缓冲区并将前导空值解释为字符串缓冲区的结尾?考虑到 Session.Property 是一个 COM 调用并且绝对应该理解 BSTR，这有点没有意义?像这样的理论永远不会正确，但也许它们至少可以帮助创造一些新的想法.似乎缺少 Windows Installer 功能，我认为有点像错误.或者就像在现实世界中一样:一个技术问题，不容易解决，因此被视为缺失的功能并被接受.
So in summary: maybe the retrieval of the multi string actually works, but the exposed value via Session.Property("PROP") erroneously reads the potential, native BSTR as a null-terminated string buffer and interprets the leading null as the end of the string buffer? Sort of doesn't make sense considering Session.Property is a COM call and should definitely understand a BSTR? Theories like these are never correct, but maybe they can help create some new ideas at least. What seemed like a missing Windows Installer feature, sort of smells like a bug I think. Or as it is in the real world: a technical problem, not easily fixed and hence seen and accepted as a missing feature.
让我将您关于此问题的问题链接在一起以供参考(以及其他一些答案):
Let me link together your questions on this issue for reference (and a couple of other answers):
这篇关于WiX RegistrySearch 对 MultiString 失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
