Question

我有一个用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'仍然最终将应用程序作为本地系统运行。< / p>

我最近从这个MSI中将VC9 CRT作为MSM包括在内，将其包含在bootstrapper exe中。

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

我做错了什么？

Answer 1

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

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

这只是在Restart Manager之前完成的。

Answer 2

我明白了。

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

在我们的wxs文件中设置ALLUSERS = 1修复了问题！

在删除CRT MSM之前和之后，WiX MSI的行为有所不同

2 个答案: