Wix - 在安装/升级期间，自定义操作的条件在不应该的情况下解析为False

Posted 2021-04-15

安装程序

所以我的InstallExecuteSequence中有一个自定义操作，如下所示：

    <Custom Action="UpdateConfigFile" After="InstallFinalize">NOT Installed OR Upgrading</Custom>    

升级定义为：

        <SetProperty After="SetFirstInstall" Id="Upgrading" Value="true">
         WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")
        </SetProperty>

自定义操作使用通过属性传递到安装程序的值更新web.config文件。这是一个VB.Net功能。

我遇到的问题

此自定义操作始终在我们的许多安装程序中执行。但是对于我们在开发中的某个环境，它的条件在安装/升级方案中解析为False。它在MSI日志中说“（条件为假）”。

该环境用于开发目的，例如在安装/更新后测试产品。

我想要完成的是什么

我希望这个解决，以便这个环境可以成功安装我们的产品。

我到目前为止做了什么

我已将相同的安装程序安装到不同的操作系统，例如Windows 10,2012 R2和2016.安装程序工作正常，因为自定义操作按预期运行。

麻烦的环境是Windows Server 2012 R2机器。这让我更加困惑。

我做了一些挖掘，只能找到这个链接：（https://blogs.msdn.microsoft.com/heaths/2006/07/11/why-a-custom-action-may-not-run/#comments）

从链接的建议，我认为如果缺少一个依赖项是非常奇怪的，因为相同的安装程序在其他机器上工作。

所以我在这一点上很难过。任何帮助或方向将非常感谢。如果我不够清楚，请随时要求更多澄清。谢谢，麻烦您了。

答案

只是一些评论要开始，这不是一个真正的答案：

• 首先要做的事情是：为了正确地传递给延迟模式（InstallExecuteSequence），属性应该是UPPERCASE（public properties），它们应该在SecureCustomProperties分隔的“安全属性”列表中列出，以传递给延迟模式。
• 除了大写它之外，我不会像这样设置一个名为Upgrading的属性，我宁愿在延迟模式（InstallExecuteSequence）中使用“原始”条件进行自定义操作。
• 以下是Flexera（Installshield的制造商）的常见情况备忘单：Common MSI Conditions Cheat Sheet。这是一个direct link to the PDF。
• 你可以看一下这个老帖子：How to add a WiX custom action that happens only on uninstall (via MSI)?。我从来没有时间测试所有这些条件，但从表面看它看起来是正确的。
• 关于特殊财产UPGRADINGPRODUCTCODE的一些注释。

---

升级：

问题：

• 那台Windows Server 2012 R2机器 - 有什么特别之处吗？安全性是否收紧？它在网络上的任务或目的是什么？
• UpdateConfigFile的实际实现是什么 - 它是一个脚本，一个用C ++编写的编译DLL，一个用.NET语言编写的托管DLL，还是别的东西？也许是EXE文件？
• 这听起来很熟悉：Installer fails on Windows Server 2012 R2
• 您是否验证此问题服务器上是否安装了正确版本的.NET框架？该功能是否以交互方式运行？如果它是DLL函数，请尝试通过测试工具EXE在该计算机上以交互方式运行该VB.NET函数。或者直接运行它是一个EXE文件直接。

另一答案

问题可能是您在InstallFinalize之后安排（由于升级属性不公开（不是大写），因此不好，请参阅后面的内容）。如果您将条件更改为WIX_UPGRADE_DETECTED AND NOT（REMOVE =“ALL”）它应该有效，假设：

1. WIX_UPGRADE_DETECTED是与主要升级相关联的实际属性，例如来自主要的uypgrade元素。
2. WIX_UPGRADE_DETECTED位于SecureCustomProperies中。

通常不建议在InstallFinalize之后执行操作，因为如果它们失败（在您的情况下搞砸了配置文件），那么就没有太多可以做的事情（例如回滚到正确的配置文件）。它在安装后有效，因此当升级版本第一次运行时，在应用程序中进行配置更改也更容易。

另一答案

在帮助负责环境的团队之后，我们发现导致此问题的是某种情况。深入研究MSI日志，我们发现在InstallFinalize之后运行的先前自定义操作正在返回失败操作结果。从那以后，不执行以下自定义操作，例如我的UpdateConfigFile自定义操作。导致日志中的“（condition is false）”条目。

一旦我们想到这一点，我就可以在我的本地环境中重现它。

由于这些自定义操作在InstallFinalize之后，我认为如果一个失败，那些自定义操作仍会运行，因为我们已经超出了安装程序能够执行回滚的程度。但我错了，现在我知道了。

感谢大家帮我解决这个问题。我开始担心我会试着弄清楚这几天，然后开始拔头发。 XD