WiX MSI 在移除 CRT MSM 之前和之后的行为不同答案

【问题标题】：WiX MSI behaves differently before and after removing CRT MSMWiX MSI 在移除 CRT MSM 之前和之后的行为不同
【发布时间】：2012-06-28 21:15:15
【问题描述】：

我有一个使用 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> 和 <MergeRef> 标签，其他没有任何变化。

我做错了什么？

【问题讨论】：

标签： wix windows-installer merge-module

【解决方案1】：

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

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

不过，这一切都发生在 Restart Manager 之前。

【讨论】：

嗯...重启管理器是否处理模拟？这可能是重做此功能的有效方法。
我不知道。从那以后再也不需要这种行为了。

【解决方案2】：

我想通了。

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

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

【讨论】：