使用 Windows Installer 启动依赖于并行程序集的服务
我们正在更新适用于 Windows Server 2008 的产品 .msi 包的构建。我们安装的主要组件是作为 Windows 服务运行的应用程序。 还有一个在安装过程中运行的配置应用程序，用于设置服务使用的注册表项。
服务和配置应用程序依赖于 Microsoft C/C++ 运行时和 MFC，它们作为合并模块包含在 .msi 中。 C/C++ 运行时和 MFC 的程序集在 InstallFinalize 期间提交，这似乎排除了使用 Windows Installer 提供的机制启动服务（这是正确的吗？）当然，我们会看到与 at 并排的错误如果配置应用程序在 InstallFinalize 之前运行，则至少需要该配置应用程序。
我们采取的方法是在 InstallFinalize 之后将配置应用程序作为“提交”自定义操作运行，并让该应用程序启动服务。 这要求应用程序以提升的权限执行（为此我们使用包含 trustInfo 部分的清单。）这进一步要求 .msi 配置为在不模拟的情况下运行此应用程序（否则会混淆权限提升）
。可接受的方法？ 这可能有多面向未来？ 有什么需要注意的问题吗？
看来这是其他人遇到的问题：
http://www.mail-archive.com/[电子邮件受保护]/msg12666.html
有吗正式的（或非官方）接受的处理此类问题的方法？
作为对此的补充，是否有任何方法可以确保在安装过程中作为自定义操作运行的应用程序在启动时获得焦点？ 以这种方式启动的应用程序似乎总是在安装程序后面弹出，并且安装程序保持焦点，这不是一个特别用户友好的效果。
非常感谢，
布鲁斯。
We are in the process of updating the construction of our product's .msi package for Windows Server 2008. The main component of our install is an application that is run as a Windows service. There is also a configuration application that gets run during install to set up registry entries for use by the service.
The service and the configuration application rely on the Microsoft C/C++ runtime and MFC, which are included in the .msi as merge modules. The assemblies for the C/C++ runtime and MFC are committed during the InstallFinalize, which seems to preclude the starting of the service using the mechanisms provided by Windows Installer (is this correct?) Certainly, we see side-by-side errors with at least the configuration application if it is run before InstallFinalize.
The approach we have taken is to run the configuration application as a "commit" custom action after InstallFinalize, and have this application start the service. This requires that the application is executed with elevated privileges (for which we use a manifest containing a trustInfo section.) This further requires that the .msi is configured to run this application without Impersonation (which otherwise confounds the privilege elevation.)
Is this an acceptable approach? How future-proof is this likely to be? Are there any gotchas to be aware of?
It seems that this is a problem that has been encountered by others:
http://www.mail-archive.com/[email protected]/msg12666.html
Is there an officially (or unofficially) accepted way to deal with such problems?
As an addendum to this, is there any way of ensuring that an application run as a custom action during the install process gets focus when it starts up? Applications started in this manner always seem to pop up behind the installer and the installer keeps focus, which is not a particularly user-friendly effect.
Many Thanks,
Bruce.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是我在使用 Windows Installer 重新打包软件时用于解决此类问题的解决方案：“引导”启动器。 简而言之，您可以执行以下操作之一，而不是使用运行时的合并模块（这些模块将与所有其他安装的文件同时提交）：
为运行时/MFC 提供可再发行的 MSI，并让它们首先由引导程序 setup.exe 启动。 当然，您的程序的 MSI 必须测试您需要的版本是否已安装，甚至可能进行测试以确保您正在从 setup.exe 运行它。 （此方法由 InstallShield 推广，因为他们喜欢围绕 Windows Installer 进行最终运行。）
更好的是，您可以将 MSI 打包为安装两个（或更多）嵌入式 MSI 的父包：首先，安装所需的运行时，然后将软件安装在子 MSI 中。 您的父包将确认运行时的 MSI 已成功安装，然后再继续安装 MSI（可以自由启动服务，因为先决条件已经存在）。
还有其他一些棘手的方法，例如早期提交的自定义操作，但它们不如我刚才提到的经过时间考验的方法那么可靠。
希望这是有道理的！ 我曾经生活和呼吸MSI，但现在不再那么多了......
Here's a solution I've used for this kind of problem when re-packaging software with Windows Installer: a "bootstrap" launcher. In short, instead of using the merge modules for the runtime (which will all commit at the same time as all your other installed files), you can do one of the following:
Provide the redistributable MSIs for the runtime/MFCs, and have them launched first by your bootstrapper setup.exe. Your program's MSI must of course test that the version you need is installed and maybe even test to ensure that you're running it from your setup.exe. (This method was popularized by InstallShield, as they like to do the end-run around Windows Installer.)
Better yet, you can package your MSI as a parent package that installs two (or more) embedded MSIs: first, install the required runtimes, then install your software in a child MSI. Your parent package will confirm that the runtimes' MSI installed successfully before continuing on to install your MSI (which has the freedom to start the services since the prerequisites are already there).
There are other tricksy methods, like your early-commit custom action, but they are not as dependable as the time-tested ones I just mentioned.
Hope that makes sense! I used to live and breathe MSI, but not so much anymore these days...