Installation 使用WiX和MSI的多产品共享组件设置？ 抛

我正在寻找关于如何为应用程序套件构建基于MSI和MSI的安装程序解决方案的高级建议

问题: 根据下面的布局当所有应用程序/功能和共享库进入同一安装目录时，安装程序套件应使用多少不同的MSI包

• 整个套件的单个MSI包显然太大（如当前系统所示）
• 每个应用程序一个（完整的）MSI包将复制应用程序之间共享的dll库，这意味着复制100 MB的dll。（另外，对我来说，MSI重新计数的未知问题）
• 每个二进制库和可执行文件一个MSI包？
  • 也就是说，许多MSI文件只包含一个DLL或一个EXE
  • 我是否可以确保仅在安装了EXE MSI软件包的必备库软件包时才安装该软件包

背景 我们的应用程序套件的布局有点像MS Office，因为我们有一个安装文件夹，其中安装了一系列应用程序及其所有共享库文件。即:

 C:\ProgramFiles\MyApplicationSuite
                                   \ - App1.exe
                                   \ - App2.exe
                                   \ - App3.exe
                                   \ - ...
                                   \ - libxy.dll
                                   \ - qt.dll
                                   \ - ...

到目前为止，我们只有一个安装程序，可以将所有应用程序作为功能安装，也就是说，Windows程序列表中只有一个程序条目。这很好，因为大部分时间整个套件都是安装的，有些安装可能不会使用一个或两个应用程序

---

由于单一的安装方法开始崩溃，公司要求迫使我切换到基于MSI的安装，我正在研究如何使用WiX以最佳方式构建这样的beast，烧录和细化MSI包。

关于拆分或合并设置主题的一些想法：。略读一下，看看是否有适用的变量（发布计划、本地化、构建速度等）

<>你可以使用或（基本上像C++中的普通头文件一样工作，它是）在几个设置中包括共享组件。然后，它们将被正确地引用计数，您可以以受控的方式向它们分发更新

就我个人而言，我喜欢将共享组件从主MSI中完全分离出来，通过一个单独的先决条件设置进行安装，然后将其捆绑在一个引导程序中，该引导程序使用Burn或等效工具包设计，以允许按顺序安装多个MSI和/或EXE文件。我发现这会产生良好的内聚/耦合。这是有争议的。当MSI包含共享的嵌入式组件（合并模块/包含文件）时，它更“独立”，但特别是对于公司部署，我喜欢将所有共享组件拆分为它们自己的必备MSI。这其中有一些非常技术性的原因，我需要比现有的更多的时间来解释

我现在就到此为止，可能会在以后返回并更新

---

一些链接（主要是为了方便检索）：

---

我想尝试一下“共享先决条件设置”这件事（如我的问题中的项目符号3所述（“每个二进制库和可执行文件一个MSI包”）。但是，与您提到的组件/片段不同，我不清楚如何进行wrt.refcounting和先决条件检查。您可以详细说明一下吗？安装在同一位置的文件应始终具有跨产品和版本的id。如果您使用一致的源pa，WiX可以为您生成id我会创建一个构建后审计工具来确保（请参阅WiX DTF或Windows Installer SDK）。正如Rob Mensching建议的那样，在发布版本1之前测试升级到原型版本2。