Wix - 在 install/upgrade 期间,自定义操作的条件在不应该时解析为 False
Wix - During install/upgrade a Custom Action's conditions resolve to False when they shouldn't
设置
所以我的 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 函数。
我运行感兴趣的问题
此自定义操作一直在我们的许多安装程序中执行。但是对于我们在开发中的某个环境,它的条件在 install/upgrade 场景中解析为 False。 MSI 日志中显示“(条件为假)”。
该环境用于开发目的,例如在 installed/updated 之后测试产品。
我正在努力实现的目标
我希望这个问题得到解决,这样这个环境才能成功安装我们的产品。
到目前为止我做了什么
我已将相同的安装程序安装到不同的操作系统,例如 Windows 10、2012 R2 和 2016。安装程序工作正常,因为自定义操作按预期运行。
麻烦的环境是一台WindowsServer 2012 R2机器。这让我更加困惑。
我做了一些挖掘,只能找到这个 link: (https://blogs.msdn.microsoft.com/heaths/2006/07/11/why-a-custom-action-may-not-run/#comments)
根据 link 的建议,我认为如果缺少依赖项真的很奇怪,因为相同的安装程序可以在其他机器上运行。
所以我现在很困惑。任何帮助或指导将不胜感激。如果我不够清楚,请随时要求更多说明。请谢谢。
只是一些评论,这不是真正的答案:
- 首先要做的事情是:为了正确传递到延迟模式 (
InstallExecuteSequence
),属性应该是大写的(public properties) and they should be listed in the SecureCustomProperties 分隔列表 "safe properties" 以传递到延迟模式。
- 除了大写之外,我不会像那样设置一个名为
Upgrading
的 属性,我宁愿在延迟模式下为自定义操作使用 "raw" 条件(InstallExecuteSequence
).
- 这是来自 Flexera(Installshield 的制造商)的常见条件的 作弊 sheet:Common MSI Conditions Cheat Sheet. And here is a direct link to the PDF。
- 你可以看看这个旧的post: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 之后(这不好,稍后见),因为升级 属性 不是 public(不是大写)。如果您将条件更改为 WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL") 它应该可以工作,假设:
WIX_UPGRADE_DETECTED 是与主要升级相关的实际 属性,例如来自主要 uypgrade 元素。
WIX_UPGRADE_DETECTED 在 SecureCustomProperies 中。
通常不建议在 InstallFinalize 之后执行操作,因为如果它们失败(在您的情况下搞砸了配置文件),那么就没有什么可以做的了(例如回滚到正确的配置文件)。它在安装后有效,因此当升级版本首次运行时,在应用程序中进行配置更改也更容易。
在帮助负责环境的团队后,我们发现是某个场景导致了这个问题。进一步深入挖掘 MSI 日志,我们发现之前的自定义操作 运行ning 也在 InstallFinalize 之后返回了失败操作结果。由于发生这种情况,以下自定义操作(例如我的 UpdateConfigFile 自定义操作)不会执行。导致日志中出现“(条件为假)”条目。
一旦我们弄明白了,我就能够在我的本地环境中重现它。
由于这些自定义操作是在 InstallFinalize 之后进行的,我认为如果失败,这些自定义操作仍会 运行,因为我们已经过了安装程序能够执行回滚的时间点。但我错了,现在我知道了。
感谢大家帮助我解决这个问题。我开始担心我会花几天时间尝试解决这个问题并开始拔头发。 XD
设置
所以我的 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 函数。
我运行感兴趣的问题
此自定义操作一直在我们的许多安装程序中执行。但是对于我们在开发中的某个环境,它的条件在 install/upgrade 场景中解析为 False。 MSI 日志中显示“(条件为假)”。
该环境用于开发目的,例如在 installed/updated 之后测试产品。
我正在努力实现的目标
我希望这个问题得到解决,这样这个环境才能成功安装我们的产品。
到目前为止我做了什么
我已将相同的安装程序安装到不同的操作系统,例如 Windows 10、2012 R2 和 2016。安装程序工作正常,因为自定义操作按预期运行。
麻烦的环境是一台WindowsServer 2012 R2机器。这让我更加困惑。
我做了一些挖掘,只能找到这个 link: (https://blogs.msdn.microsoft.com/heaths/2006/07/11/why-a-custom-action-may-not-run/#comments)
根据 link 的建议,我认为如果缺少依赖项真的很奇怪,因为相同的安装程序可以在其他机器上运行。
所以我现在很困惑。任何帮助或指导将不胜感激。如果我不够清楚,请随时要求更多说明。请谢谢。
只是一些评论,这不是真正的答案:
- 首先要做的事情是:为了正确传递到延迟模式 (
InstallExecuteSequence
),属性应该是大写的(public properties) and they should be listed in the SecureCustomProperties 分隔列表 "safe properties" 以传递到延迟模式。 - 除了大写之外,我不会像那样设置一个名为
Upgrading
的 属性,我宁愿在延迟模式下为自定义操作使用 "raw" 条件(InstallExecuteSequence
). - 这是来自 Flexera(Installshield 的制造商)的常见条件的 作弊 sheet:Common MSI Conditions Cheat Sheet. And here is a direct link to the PDF。
- 你可以看看这个旧的post: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 之后(这不好,稍后见),因为升级 属性 不是 public(不是大写)。如果您将条件更改为 WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL") 它应该可以工作,假设:
WIX_UPGRADE_DETECTED 是与主要升级相关的实际 属性,例如来自主要 uypgrade 元素。
WIX_UPGRADE_DETECTED 在 SecureCustomProperies 中。
通常不建议在 InstallFinalize 之后执行操作,因为如果它们失败(在您的情况下搞砸了配置文件),那么就没有什么可以做的了(例如回滚到正确的配置文件)。它在安装后有效,因此当升级版本首次运行时,在应用程序中进行配置更改也更容易。
在帮助负责环境的团队后,我们发现是某个场景导致了这个问题。进一步深入挖掘 MSI 日志,我们发现之前的自定义操作 运行ning 也在 InstallFinalize 之后返回了失败操作结果。由于发生这种情况,以下自定义操作(例如我的 UpdateConfigFile 自定义操作)不会执行。导致日志中出现“(条件为假)”条目。
一旦我们弄明白了,我就能够在我的本地环境中重现它。
由于这些自定义操作是在 InstallFinalize 之后进行的,我认为如果失败,这些自定义操作仍会 运行,因为我们已经过了安装程序能够执行回滚的时间点。但我错了,现在我知道了。
感谢大家帮助我解决这个问题。我开始担心我会花几天时间尝试解决这个问题并开始拔头发。 XD