0

我有一个用 WiX 构建的 MSI。它执行以下自定义操作：

     <CustomAction Id='StartTray'
                   Directory='INSTALLDIR'
                   ExeCommand='[INSTALLDIR]\myapptray.exe'
                   Return='asyncNoWait'
                   Impersonate='no'
                   Execute='deferred' />

它是这样安排的：

        <Custom Action='StartTray' After='StartServices'>NOT Installed OR (TRAYWASRUNNING AND NOT REMOVE~="ALL")</Custom>

myapptray.exe作为当前在桌面上活动的用户，碰巧使用模拟从其本地系统的起始上下文（从 MSI 上下文运行）重新启动自身。这不在我的控制范围内，并且 Impersonate='yes' 不起作用，因为可能会调用 MSI 以从系统服务的上下文进行升级，这意味着 Impersonate='yes' 最终仍将应用程序作为本地系统运行。

我最近从将 VC9 CRT 作为 MSM 包含在此 MSI 中，将其包含在引导程序 exe 中。

这样做会阻止myapptray.exe自定义操作成功运行。模拟失败，WTSQueryUserToken其中返回ERROR_PRIVILEGE_NOT_HELD。这似乎意味着删除 MSM 实际上改变了运行 MSI 的用户上下文，但这似乎很荒谬。我从 wxs 文件中删除的唯一行是 MSM 的<Merge>and<MergeRef>标记，没有其他任何更改。

我究竟做错了什么？

4

2 回答 2

1

我会更多地查看您的 EXE 是针对哪些版本的 CRT 构建的，以及是否有任何策略规则说明它可以运行的内容。在您的 MSI 之前从 MSM 转移到 EXE 运行通常应该是一件好事。

顺便说一句，我曾经做过类似这样的黑客行为。我们不得不使用 MSI 在 SYSTEM 上下文中推出一个 MSI。如果用户已登录，我们必须使用用户桌面登录会话重新启动应用程序。我安装了一个配置为模拟交互式用户来完成此操作的 DCOM 服务器。真的很奇怪，但有一个正当的理由。

不过，这一切都发生在重新启动管理器之前。

于 2012-06-29T20:38:50.947 回答
0

我想到了。

CRT MSM 设置 ALLUSERS=1 并且安装程序的行为发生了变化，因为它在我们的基本安装程序中不存在。因此，MSM 的 ALLUSERS 设置被继承到基本安装程序中。

在我们的 wxs 文件中设置 ALLUSERS=1 解决了这个问题！

于 2012-07-23T18:48:28.773 回答