Windows Installer 自定义操作:不会执行提交操作 [英] Windows Installer custom actions: commit action won't get executed

问题描述

我正在使用 WIX 设计一个 Windows 安装程序项目.现在它在安装中失败了，因为 Commit 自定义操作不会被执行，这很奇怪，因为预定的后续自定义操作有一个返回 ActionResult.Success 的路线.让我详细解释一下:

I am designing a windows installer project using WIX. Now it fails in the installation, because the Commit custom action won't get executed, which is caused, weirdly, because a scheduled following custom action has one route to return ActionResult.Success. Let me explain in details:

基本上，我有两个关于安装的自定义操作:一个称为 CommitCA，另一个称为 InstallCA.执行时间表如下:

Basically I have two custom actions regarding to installation: one called CommitCA and one called InstallCA. The execution schedule is listed as below:

<CustomAction Id="CommitCA" BinaryKey="CustomActionDll" DllEntry="CommitCA" Execute="commit" Return="check" Impersonate="no"/>
<CustomAction Id="InstallCA" BinaryKey="CustomActionDll" DllEntry="InstallCA" Execute="deferred" Return="check" Impersonate="no"/>

我已从 ORCA 验证，在编译的安装程序中，CommitCA 安排在 InstallCA 之前.CommitCA 的类型是 3585，InstallCA 是 3703(我找不到对它们的引用，但我假设一个用于提交操作，另一个是我声明的延迟操作).这个想法是在 CommitCA 中，它将生成一些将由 InstallCA 使用的文件.

I have verified from ORCA that in the compiled installer, the CommitCA is scheduled before InstallCA. The type of CommitCA is 3585 and InstallCA is 3703 (I can't find the reference to them but I assume one is for commit action and the other is defered action like I declared). The idea is in the CommitCA it will generate some file which will be used by InstallCA.

我的 InstallCA 的结构如下所示:

The structure of my InstallCA looks like this:

Try
    ' Do some work
    ...

Catch ex As Exception
    ' Log the failure into installation log
    Return ActionResult.Failure
End Try
Return ActionResult.Success

这是令人困惑的部分:最初我有一个工作版本，我没有在 Catch 块中返回 ActionResult.Failure 的行.换句话说，该函数仍然记录失败，但即使抛出异常，最终也会返回 Success.我觉得这有点误导，因为有时当发生异常并且我检查日志时，它会说自定义操作成功.这就是我添加该行的原因

Here comes the confusing part: originally I have a working version, where I didn't have the line of returning ActionResult.Failure in the Catch block. In another word, the function still logs the failure, but eventually returns Success even if an exception was thrown. I find it a bit misleading, because sometimes when an exception happens and I check the log, it says the custom action succeeded. That's why I added the line

        Return ActionResult.Failure

但是，现在它不再起作用了！每当我安装时，我发现我的 CommitCA 永远不会被执行.注意:不是 InstallCA，它有我所做的唯一代码修改，而是 CommitCA，它实际上是在 InstallCA 之前安排的.当我说永远不会被执行"时，我的意思是我找不到放在函数调用中的任何日志条目，并且 MMSIBREAK 环境变量甚至根本不起作用(窗口通知我附加到rundll32进程永远不会弹出).但是下面的 InstallCA 仍然会被执行.

However, now it doesn't work anymore! Whenever I install, I find that my CommitCA never gets executed. NOTE: not the InstallCA, which has the only code modification I made, but the CommitCA, which is actually scheduled before the InstallCA. And when I say "never gets executed", I mean I can't find any log entry which I put inside the function calls, and MMSIBREAK environment variable doesn't even work at all (the window informing me to attach to the rundll32 process never pops up). But the following InstallCA still gets executed.

如果我注释掉 Return ActionResult.Failure 行，一切都会恢复正常:我可以附加进入 CommitCA 并调用 InstallCA也是.

If I comment out the line Return ActionResult.Failure, everything works again: I can attach to get into CommitCA and InstallCA gets called as well.

我对自定义操作的返回结果可能有一些误解.在这种情况下我不应该返回 ActionResult.Failure 吗?但实际上我在其他一些地方也返回了 ActionResult.Failure .事实上，在 CommitCA 函数本身中，我使用了相同的结构:在 Catch 块中返回 ActionResult.Failure.那么有人能告诉我我做错了什么吗?

There is probably something that I misunderstood about the return result of custom action. Am I not supposed to return ActionResult.Failure in this situation? But actually I return ActionResult.Failure in some other places too. In fact in the CommitCA function itself, I used the same structure: returning ActionResult.Failure in the Catch block. So could anybody tell me what I did wrong?

推荐答案

我会从阅读开始:

Windows Installer 中自定义操作的安装阶段和脚本内执行选项

关于提交 CA 的一些需要了解的事情:

A few things to understand about commit CA's:

提交自定义操作通常并不意味着更改机器的状态.它们旨在清理回滚临时数据.

Commit custom action are generally not meant to change the state of the machine. They are meant to cleanup rollback temp data.

如果回滚被禁用(通过属性或系统策略)，则不会执行提交自定义操作，因为这意味着没有要清理的回滚数据.

Commit custom actions do not execute if rollback is disabled (by property or system policy) because that would mean there is no rollback data to clean up.

当无法进行回滚并且您希望尽可能晚地推迟更改时，有时会使用提交自定义操作来配置机器.(更改用户密码，将 DLL 安装到 GAC)在这些情况下，成本核算应指示延迟的自定义操作来完成工作，因为回滚/提交永远不会执行.

Occasionally commit custom actions are used to configure the machine when it's not possible to do a rollback and you want to defer the change until as late as possible. (Changing a user password, installing a DLL to the GAC ) In these scenarios costing should instruct the deferred custom action to do the work since the rollback/commit will never execute.

回滚自定义操作应安排在延迟自定义操作之前，提交操作应安排在延迟自定义操作之后.这样脚本生成阶段才能正确创建脚本.

Rollback custom actions should be scheduled before the deferred custom action and commit actions should get scheduled after the deferred custom action. This is so that the script generation phase can create the script correctly.

如果延迟阶段失败，脚本将向后走，以便执行回滚.

If the deferred phase fails, the script is walked backwards so that the rollbacks are executed.

如果所有延迟阶段都成功，则提交脚本将向前执行.这意味着所有延迟的 CA 必须在任何提交执行之前完成.

If all of the deferred phase succeeds, the commit script is executed walked forwards. This means that all deferred CA's must finish before any of the commits execute.

这篇关于Windows Installer 自定义操作:不会执行提交操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！