使用 WiX 和 MSI 的多产品共享组件设置? [英] Multi-Product Shared Component Setup with WiX and MSI?
问题描述
我正在寻找有关如何构建 WiX 和 Burn 应用程序套件的基于 MSI 的安装程序解决方案.
I'm looking for high level advise on how to structure a WiX and Burn MSI based installer solution for an application suite.
鉴于下面的布局，当所有应用程序/功能和共享库进入同一安装目录时，安装程序套件应使用多少个不同的 MSI 包?
Given the layout below how many distinct MSI packages should an installer suite utilize when all apps/features and shared libs go into the same installation directory?
- 整个套件的单个 MSI 包显然太大(如当前系统所示)
- 每个应用程序一个(完整的)MSI 包会复制应用程序之间共享的 dll 库，这意味着复制 100 MB 的 DLL.(另外，对我来说，MSI refcounting 令人头疼)
- 每个二进制库和可执行文件一个 MSI 包?
- 即，许多 MSI 文件只包含一个 DLL 或一个 EXE
- 我能否确保 EXE MSI 包仅在其必备库包已安装时才安装?
我们的应用程序套件的布局有点像 MS Office，因为我们有 一个 安装文件夹，其中安装了一系列应用程序及其所有共享库文件.那就是:
Our application suite is layed out a bit like MS Office in that we have one installation folder where a series of applications is installed to together with all their shared library files. That is:
C:ProgramFilesMyApplicationSuite - App1.exe - App2.exe - App3.exe - ... - libxy.dll - qt.dll - ...到目前为止，我们只有一个 InnoSetup 安装程序，它可以安装所有应用程序作为功能，也就是说，Windows 程序列表中只有一个程序条目.这很有效，因为大多数时候整个套件都安装好了，有些安装可能不会使用一两个应用程序.
Up until now, we had one single InnoSetup installer, that could install all of the apps as features, that is, there was only one single Programs entry in the Windows Programs list. This worked well because most of the time the whole suite was installed anyway, and some installations would maybe not use one or two apps.
由于单一设置方法开始被打破，并且企业要求迫使我切换到基于 MSI 的安装，我正在研究如何使用 WiX、Burn 和粒度 MSI 包以最佳方式构建这样一个野兽.
Since the single setup approach start to break, and Corporate Requirements force me to switch to an MSI based installation, I'm looking into how to structure such a beast the best way using WiX, Burn and granular MSI packages.
推荐答案
您已经就拆分或合并设置的主题提出了一些想法:Wix 安装多个应用程序.浏览一下，看看是否有任何适用的变量(发布时间表、本地化、构建速度等).
Some thoughts along the lines of what you already state on the topic of splitting or merging setups: Wix to Install multiple Applications. Have a skim of this and see if there are any variables that apply (release schedule, localization, build speed, etc...).
您可以使用 合并模块或WiX包含文件(基本上像一个包含在 C++ 中的普通头文件，它是一个 预处理器操作)在多个设置中包含共享组件.然后它们将被正确地引用计数，并且您可以以受控的方式向它们分发更新.
You can use merge modules or WiX include files (basically works like a normal header file include in C++, it is a preprocessor operation) to include shared components in several setups. They will then be properly reference counted and you can distribute updates to them in a controlled fashion.
就我个人而言，我喜欢将共享组件完全从我的主 MSI 中分离出来，并通过单独的先决条件设置来安装它们，然后将它们全部捆绑在一个引导程序中，该引导程序由 Burn 或旨在允许安装多个 MSI 和/或 EXE 的等效工具包制作文件顺序.我发现这会产生良好的内聚/耦合.这是值得商榷的.当 MSI 包含共享的嵌入式组件(合并模块/包含文件)时，它更加独立"，但特别是对于企业部署，我喜欢将所有共享组件拆分为它们自己的必备 MSI.这有一些非常技术性的原因，我需要更多的时间来解释而不是可用的.
Personally I like to split shared components completely away from my main MSI and install them via a separate prerequisite setup and then bundle it all together in a bootstrapper made with Burn or equivalent toolkits designed to allow installation of several MSI and / or EXE files in sequence. I find this yields good cohesion / coupling. This is debatable. An MSI is more "self-contained" when it contains shared, embedded components (merge modules / include files), but particularly for corporate deployment I like to split all shared components to their own prerequisite MSI. There are some very technical reasons for this that I would need more time to explain than what is available.
我将暂时保留它，稍后可能会返回并更新.
I will leave it at that for now, possibly returning and updating later.
一些链接(主要是为了方便检索):
Some Links (primarily for easy retrieval):
- 如何使用 WiX 表达文件依赖关系
- WiX (Windows Installer Xml)，创建通用变量
- Wix 安装程序:在命令行执行 MSIEXEC 管理员安装时设置组件条件属性
- 将模块文件合并到不同的位置
- MSI 引用计数:两个产品安装相同的 MSI
这篇关于使用 WiX 和 MSI 的多产品共享组件设置?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
