可以在其他安装程序中使用基于 WiX 的 Windows 安装程序吗?

问题描述

使用 WiX 引导程序构建的设置通常能够在其他安装程序中运行吗?

Is a setup built using WiX bootstrapper generally capable of running within other installers?

我想要创建一组可分发的文件，其中包含一个 api dll、一个安装程序，用于安装 API 使用的服务以及任何必备文件(VC++、.NET 框架等).此设置将由 Wix 引导程序构建到 .exe 文件中.然后，最终客户可以将我们的 .exe 设置放入他们的安装程序中并静默运行以安装运行我们的 API 所需的一切.

I am wanting to create a distributable set of files that contains an api dll, a setup program that installs a service the API uses and any prerequisite files (VC++, .NET framework, etc). This setup would be built by Wix bootstrapper into a .exe file. End customers could then drop our .exe setup into their installer and run it silently to install everything needed to run our API.

推荐答案

简答: 您的 setup.exe 可以通过以下方式安装另一个 setup.exe 只要它不会同时安装多个 MSI 文件，并且另一个 setup.exe 也按顺序运行，而不会产生多个 MSI 安装一次.技术说明如下.

The Short Answer: Your setup.exe can be installed by another setup.exe as long as it does not kick of several MSI files to install concurrently, and the other setup.exe also runs things in sequence without spawning multiple MSI installs at once. Technical explanation below.

基本上，您可以将设置作为 setup.exe、MSI 或 合并模块 或以上所有方式提供.

Essentially you can deliver your setup as a setup.exe, an MSI or as a merge module or all of the above.

更新:我想看看你是否熟悉 WiX 包含文件?

UPDATE: I want to check if you are familiar with WiX include files?

InstallExecuteSequence Mutex:由于非常基本的技术原因(a mutex 在 InstallExecuteSequence 在 InstallInitialize 之间运行时设置> 和 InstallFinalize).

InstallExecuteSequence Mutex: Two MSI files can not run their actual install operations (the actions that actually change the system) concurrently for very fundamental, technical reasons (a mutex is set when the InstallExecuteSequence runs between InstallInitialize and InstallFinalize).

多个 MSI GUI:我已经多次写过这个问题，但我认为最直接的解释是 这个来自 serverfault.本质上，系统被锁定以确保在安装过程中发生错误时可以回滚所有更改.应该注意的是，您可以一次启动多个 MSI 文件并进入它们的 GUI 序列(换句话说，显示准备实际安装的设置对话框)，但您一次只能启动一个进行实际系统更改 - 在技术上表示运行 InstallExecuteSequence 的术语.

序列化的 MSI 文件:MSI 文件可以一个接一个地"运行而不会出现问题，只要它们都经过精心设计.WiX 引导程序 Burn 专门为此目的(以及其他一些免费用途:下载器、引导程序、排序器、允许外部、自定义设置 GUI 等...).

Sequenced MSI Files: MSI files can run "one after the other" without problems, provided they are all well designed. The WiX bootstrapper Burn is made specifically for this purpose (and a few other complimentary purposes: downloader, bootstrapper, sequencer, allow external, custom setup GUI, etc...).

可能的方法:您的设置似乎将包含在其他软件套件的安装中?这里有几个选项.

Potential Approaches: It seems your setup will be included as part of other software suite's installations? There are several options here.

• 按顺序运行:如果其他软件供应商对此表示同意，他们可以将您的 setup.exe 包含在他们的并让它运行完成，然后再继续自己的设置.这意味着他们使用 WiX (Burn) 创建的自己的 setup.exe 或使用 Advanced Installer、Installshield 或其他商业工具生成的等效 setup.exe 执行此操作(甚至只是 dotnetInstaller - 这是一个免费的引导程序).

• Run in Sequence: If the other software vendor is OK with this, they can include your setup.exe in theirs and let it run to completion before continuing with their own setup. That would mean them doing this from their own setup.exe created with WiX (Burn), or an equivalent setup.exe generated using Advanced Installer, Installshield or another commercial tool (or even just dotnetInstaller - which is a free bootstrapper).

合并模块(赛门铁克文章):或者，您可以制作一个从您自己的设置中合并模块" - 这是一个可消耗的二进制捆绑包"，可以在编译/构建时合并到任何 MSI 设置中.它是一个小数据库片段，如果您愿意，也可以是部分数据库.它将包含您设置为以适当方式安装的所有组件.本质上，合并模块是将您的设置作为可消耗的整个组件交付，它成为其他设置的实际部分 - 无需作为单独的先决条件设置进行安装.换句话说，它是交付运行时的另一种方式，无需交付单独的设置.这是 MSI 最初打算如何部署先决条件的方式，现在基本上仍然是 - 尽管现在存在诸如 Burn 之类的替代方案.

Merge Module (a Symantec article): Alternatively you can make a "merge module" out of your own setup - which is a consumable, binary "bundle" that can be merged into any MSI setup at compile / build time. It is a little database fragment, or a partial database if you like. It will contain all your components set to install in an appropriate fashion. Essentially the merge module is your setup delivered as a consumable, whole component that becomes an actual part of other setups - without installing as a separate pre-requisite setup. In other words it is an alternative way to deliver your runtime, without delivering a separate setup. It is how MSI originally intended for pre-requisites to be deployed, and it basically still is - althought alternatives such as Burn now exists.

• 制作合并模块:高级安装程序 (合并模块一般信息)，WiX(也许检查 IsWiX 的安装程序源，它使用合并模块)，Installshield (合并模块项目).

• Making merge modules: Advanced Installer (merge modules general info), WiX (maybe check IsWiX's installer source, it uses merge modules), Installshield (merge module projects).

真实故事:很多人喜欢合并模块.我不得不承认我不是一个超级粉丝，但如果做得好，它们会很好地工作.有时我不得不处理合并模块，这些模块破坏了完美的设置，因为它们具有令人难以置信的内置设计缺陷(我想到了过去的 SOAP 合并模块 - 它彻底 - 并且单枪匹马 - 引发了我的设置错误率，必须删除).不是合并模块本身作为一种技术的问题，而是不止一次引起问题的实际问题.

Real-World Story: Many people like merge modules. I have to admit that I am not a huge fan, but when done right they work quite well. At times I have been forced to deal with merge modules that ruin perfectly good setups with their incredible built-in design flaws (the SOAP merge module from back in the day comes to mind - it drastically - and single-handedly - raised my setup's error rate and had to be removed). Not a problem of merge modules per-se as a technology, but practical issues that more than once have caused problems.

故事的寓意:不要提供一个糟糕的合并模块，其中包含许多失败的自定义操作和奇怪的要求，这些要求会使父设置"变得臃肿，并带有不必要的脆弱性和内容.如果您提供了一个符合标准的合并模块，它最小化"地完成其任务 - 那么这是部署您的运行时的好方法，甚至是一些供应商的首选.

The moral of the story: don't deliver a bad merge module with lots of custom actions that fail and weird requirements that bloat the "parent setup" with unnecessary frailty and content. If you deliver a standards-compliant merge module that does its task "minimally" - then that is a good way to deploy your runtime and even preferred by some vendors.

Core OS Runtimes:我建议不要将 .NET 框架与您的设置捆绑在一起 - 特别是如果它用于企业用途.Dot NET 现在几乎可以通过操作系统本身随时使用，并且设置中包含的运行时很快就会变得过时膨胀和肥胖"，企业应用程序打包者将花费大量时间从您的包中摆脱出来.Dot NET 更新最好通过 Windows Update(或等效的公司部署机制)分发.

Core OS Runtimes: I would recommend to not bundle the .NET framework with your setup - especially if it is for corporate use. Dot NET is now close to being always available via the OS itself, and the runtimes included in setups will quickly merely be outdated bloat and "fat" that corporate application packagers will spend a great deal of time getting rid off from your package. Dot NET updates are best distributed via Windows Update (or equivalent corporate deployment mechanisms).

相反，使用 一页 (PDF) 文档解释似乎是一种正常的方法(请参阅页面下方) 您的应用程序需要哪些先决条件才能正常运行.当然，对于合并模块组件，您会记录这一点，因为您不能将核心运行时包含在您自己的合并模块中 - 通常您只能安装自己的文件.

Instead it seems to be a normal approach to have a one-page (PDF) document explaining (see a bit down the page) what pre-requisites your application needs in order to operate properly. Certainly for a merge module component you would document this as you can't include core runtimes with your own merge module - generally you can only install your own files.

一些链接(仅供参考):

• 可以 Windows 安装程序同时安装两个msi文件?
• 为什么 Windows Installer 只能一次安装一个程序?
• 其他安装正在进行中挂起我的 Wix 安装
• Wix 自定义操作序列
• 先决条件按钮已禁用 - MSI 安装程序
• 如何制作一个自动安装应用程序所有必备程序的安装程序
• Wix - 如何在没有的情况下运行/安装应用程序界面

这篇关于可以在其他安装程序中使用基于 WiX 的 Windows 安装程序吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！