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

查看:98
本文介绍了Windows Installer自定义操作:提交操作将不会执行的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用WIX设计Windows安装程序项目。现在它安装失败,因为将无法执行提交自定义操作,这是奇怪的,因为计划的以下自定义操作具有一种返回 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 看起来像这样:

Try
    ' Do some work
    ...

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

这是令人困惑的部分:最初,我有一个工作版本,没有返回 ActionResult的行。 捕获块中的失败。换句话说,该函数仍然记录失败,但是即使抛出异常,最终也会返回成功。我发现这有点误导,因为有时当发生异常并检查日志时,它表示自定义操作已成功。这就是为什么我在行

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.

如果我将行注释掉,则返回ActionResult 。失败,一切再次正常:我可以附加到 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 函数本身中,我使用了相同的结构:在<$ c $中返回 ActionResult.Failure c>捕获块。那么有人可以告诉我我做错了什么吗?

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?

推荐答案

我将从以下内容开始阅读:

I would start by reading:

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆