从 msi 安装程序启动依赖于 msi 安装的程序集的服务
我正在使用 WiX 编写 MSI 安装程序来启动依赖于 MSI 安装的 DLL 的服务。在 Vista 上，DLL 在 MSI 的 InstallFinalize 阶段添加到全局程序集缓存中，因此我无法在 WiX 中使用内置服务启动命令。该尝试在 DLL 进入 GAC 之前启动服务，但失败了。解决方案似乎是使用自定义操作 [1]，并在 InstallFinalize 之后运行该操作。
我使用的自定义操作是使用 sc 启动服务。以管理员身份运行安装程序时一切正常，但以普通用户身份运行则不起作用。安装程序将提升实际安装阶段的权限，但在完成安装后将删除它们，并且以非特权用户身份使用 sc 启动服务将会失败。在 InstallFinalize 之后，将自定义操作设置为延迟且不模拟以获取管理员权限也不起作用 [2]。
作为最后的拼凑，我尝试将 Privileged 值被设置为 1，可能是在主安装序列被授予更高权限时。
那么其他人是否遇到过 Vista、非管理员用户、安装程序需要启动服务以及服务需要在安装过程中进入 GAC 运行的内容的组合？有没有什么通用的方法可以解决这个问题？
I'm using WiX to write a MSI installer to start a service that depends on DLLs installed by the MSI. On Vista, the DLLs become added to the global assembly cache in the MSI's InstallFinalize phase, so I can't use the built-in service starting command in WiX. That one tries to start the service before the DLLs are in the GAC, and fails. The solution seems to be to use a custom action instead [1], and run that after InstallFinalize.
The custom action I used was starting the service with sc. Everything works fine when running the installer as an administrator, but running as a regular user doesn't work. The installer will elevate privileges for the actual install phase, but will drop them after finalizing the installation, and starting the service with sc as a non-privileged user will fail. Setting the custom action to be deferred and no-impersonate to get admin privileges won't work either after InstallFinalize [2].
As a final kludge, I tried to add <Condition>Privileged</Condition> to the WiX file to tell the user that the installer needs to be run as Administrator, but I couldn't get that to work either. The Privileged value gets set to 1 during the installation, maybe when the main install sequence is given higher privileges.
So has anyone else ran into the combination of Vista, non-Administrator user, installer needs to start a service and service needs stuff that goes into GAC during installation to run? Is there any kind of working general approach to this?
[1] http://www.mail-archive.com/[email protected]/msg09162.html
[2] http://www.mail-archive.com/[email protected]/msg15381.html
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是最简单的解决方案就是安排重新启动的时候之一。
This is one of those times when the easiest solution is just to schedule a reboot.
以下是一些可能性：
如果可能，请不要在 GAC 中安装必备程序集。这将使您的服务正常启动（即在 InstallInitialize 和 InstallFinalize 之间）。
创建引导程序（按特定顺序启动必备 MSI 的小应用程序）。将必备程序集（位于 GAC 中的程序集）放入其自己的 MSI 中，并让引导程序在安装您的服务之前安装它们。
创建一个启动器（一个更小的应用程序，仅启动您的 MSI）。给它一个清单，使其运行提升。这样，整个 MSI 都会提升，而不仅仅是 InstallInitialize 和 InstallFinalize 之间的部分。您应该能够成功调用
sc。Here are a few possibilities :
If possible, do not install prerequisite assemblies in the GAC. This will allow your service to be started normally (ie between InstallInitialize and InstallFinalize).
Create a bootstrapper (a small app that launches prerequisite MSIs in a certain order). Place the prerequisite assemblies (those that go in the GAC) into their own MSI, and get the bootstrapper to install them before it installs your service.
Create a launcher (an even smaller app that just launches your MSI). Give it a manifest that will make it run elevated. That way, the entire MSI is elevated, not just the part that's between InstallInitialize and InstallFinalize. You should be able to invoke
scsuccesfully.我同意@sascha。在这种情况下，重新启动不仅是最简单的，而且是最干净的。所有其他建议的解决方案都会让您在未来面临更高的故障率。恕我直言，GAC 的 Windows Installer 设计已被破坏。重启就是对这一点的认可。
I agree with @sascha. Rebooting is not just the easiest but cleanest in this case. All of the other proposed solutions are going to set you up for a much higher failure rate in the future. IMHO, the Windows Installer design w.r.t. the GAC is busted. The reboot is recognition of that.