如何让 ARP 运行安装程序的引导应用程序以进行修改安装？
我正在开发一个安装程序项目，该项目包含一个 MSI 文件和一个管理先决条件的引导应用程序； 由于某些先决条件的需要取决于用户选择安装的功能，因此引导应用程序还提供了 UI。 当用户想要运行修改安装时，我希望能够强制添加/删除程序（或程序和功能）控制面板 (ARP) 运行引导应用程序而不是 MSI。 我尝试将安装程序的卸载注册表项下的修改路径值更改为引导应用程序的路径，但无济于事。 单击 ARP 中的“更改”按钮仍然可以获得 MSI。
有没有一种简单的方法可以做我想做的事？ 如果做不到这一点，有没有办法让 MSI 使用“更改”按钮检测到它是从 ARP 运行的，以便我可以让它显示一条错误消息，告诉用户运行引导程序应用程序？ （即，ARP 是否使用与用户用来运行 MSI 并指定修改安装相同的命令行参数，而无需查看 UI 的维护页面？如果不是，我应该寻找什么？
）编辑我的安装程序不仅安装一个应用程序，而且安装一套应用程序，每个应用程序都允许用户选择不安装。 （我们将这些应用程序作为一个套件进行安装，因为它们中的大多数都依赖于其中一个应用程序的安装。因此，对于用户来说，让一个安装程序处理所有这些应用程序会更容易，而不是使用单独的安装程序来处理它们。这个新的安装程序将被替换。）
套件中的应用程序并不都需要相同的先决条件集，因此，MSI 很难检查先决条件，直到它知道用户想要套件中的哪些应用程序安装。 此外，我们希望通过自动启动用户想要安装的应用程序的所有先决条件的安装程序来使用户更容易。 （这是在引导程序应用程序中实现安装程序 UI 的主要原因。）
MSI 是否可以启动引导程序应用程序，然后在引导程序应用程序继续运行时立即静默退出，最终重新启动 MSI？ （当引导程序应用程序启动 MSI 时，它传递到 MSI 的命令行参数之一是一个属性，告诉它引导程序应用程序启动了它。目前除其他外，它还用于允许 MSI 显示错误消息告诉用户运行引导应用程序，除非在命令行上指定了卸载或修复安装。）
I'm working on an installer project that consists of an MSI file and a bootstrap application that manages the prerequisites; and since the need for some of the prerequisites depends on what features the user chooses to install, the bootstrap app also provides the UI. I want to be able to force the Add/Remove Programs (or Programs and Features) control panel (ARP) to run the bootstrap application instead of the MSI when the user wants to run a modify install. I've tried changing the ModifyPath value under the installer's Uninstall Registry key to the path of the bootstrap application, but to no avail. Clicking the Change button in the ARP still gets me the MSI.
Is there an easy way to do what I want? Failing that, is there a way for the MSI to detect that it was run from the ARP using the Change button so that I could get it to show an error message that tells the user to run the bootstrap app instead? (I.e., does the ARP use the same command line arguments that a user would use to run the MSI and specify a modify install without having to see the maintenance page of the UI? If not, what should I look for?)
Edit My installer is installing not just one application, but a suite of applications, each of which the user is allowed to choose not to install. (We're installing these applications as a suite, because most of them depend on one of them in particular being installed. Therefore, it'll be easier on the user to have just one installer handle them all, rather than the separate installers that this new installer is going to replace.)
The applications in the suite don't all require the same set of prerequisites, therefore, it is not easy for the MSI to check for the prerequisites until it knows which applications in the suite the user wants to install. Furthermore, we want to make it easy for the user by having the installers for all of the prerequisites for the applications that the user does want installed launched automatically. (This is the main reason why the installer's UI was implemented in the bootstrap app.)
Is it possible for the MSI to launch the bootstrap app and then silently exit immediately while the bootstrap app carries on, eventually relaunching the MSI? (When the bootstrap app launches the MSI, one of the command line args it passes into the MSI is a property that tells it that the bootstrap app launched it. This is currently used, among other things, to allow the MSI to show an error message telling the user to run the bootstrap app unless an uninstall or repair install was specified on the command line.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
添加/删除程序将仅运行您的 MSI，不支持查找或运行任何引导程序应用程序。
您可以（并且应该）做的是向您的 MSI 添加先决条件检查，无论它如何运行。 通过这种方式，您可以警告用户他们正在请求当前无法完成的任务（添加尚不具备先决条件的功能）。
如果缺少先决条件，您可以添加有关运行引导程序的消息。
Add/Remove Programs will only run your MSI, there is no support for finding or running any bootstrapper apps.
What you can (and should) do is add prerequisite checking to your MSI regardless of how it is run. That way you can warn the user that they are asking for something that can not currently be accomplished (adding a feature that doesn't have its prerequisites yet).
You could add a message about running the bootstrapper instead if a prereq is missing.
通过让 MSI 为我启动引导应用程序，我解决了我的困境。 我只是编写了一个自定义操作来启动引导应用程序，并且不等待它完成。 最初，我尝试将自定义操作放入 UI 序列中，但我无法在不生成错误的情况下结束安装。
由于我的目标是仅针对“修改”安装运行引导程序，因此我在“维护”对话框的“下一步”按钮上放置了几个新的控制事件（用户在“修改”、“修复”和“删除”之间进行选择）。 如果用户选择了维护（MaintenanceMode ~=“修改”），则会启动自定义操作，并使用以 Exit 作为参数的 EndDialog 操作来关闭对话框。 （我将进入下一个对话的现有控制事件的条件修改为导致启动引导程序的条件的负数，即 NOT（MaintenanceMode ~=“修改”）。）引导程序应用程序被编程为跳过其 GUI 中的维护对话框并从序列中的下一个对话框开始，尽管用户可以选择返回到维护对话框。 （如果他这样做，引导应用程序只会返回到其维护对话框的版本，该版本看起来与 MSI 中的版本非常相似。）
我知道，这有点混乱，但它做了我需要它做的事情。 :-)
I was able to solve my dilemma by getting the MSI to launch the bootstrap app for me. I simply wrote a custom action that launches the bootstrap app and does not wait for it to finish. Initially, I tried to put the custom action into the UI sequence, but I couldn't end the install without generating errors that way.
Since my goal was to run the bootstrap only for Modify installs, I put a couple of new control events on the Next button of the Maintenance dialogue (where the user chooses between Modify, Repair and Remove). If the user has chosen Maintenance (MaintenanceMode ~= "Modify"), the custom action is launched, and the dialogue is dismissed using the EndDialog action with Exit as the argument. (I modified the condition on the existing control event that goes to the next dialogue to be the negative of the one that causes the bootstrap to be launched, i.e., NOT (MaintenanceMode ~= "Modify").) The bootstrap app is programmed to skip past the Maintenance dialogue in its GUI and start off at the next dialogue in the sequence, although the user is permitted to go back to the Maintenance dialogue if he so chooses. (If he does, the bootstrap app simply goes back to its version of the Maintenance dialogue, which looks very similar to the one in the MSI.)
I know, it's a bit of a kludge, but it does what I need it to do. :-)
我知道现在已经晚了，但是 Brad Heath 对此确实有一些评论
http://blogs.msdn .com/b/heaths/archive/2005/08/16/a-reason-for-arpsystemcomponent.aspx
I know it's late, however Brad Heath does have some comments about this
http://blogs.msdn.com/b/heaths/archive/2005/08/16/a-reason-for-arpsystemcomponent.aspx