MS安装程序/Wix中的依赖项

我目前正在学习WiX和Windows installer的变幻莫测之处，我遇到了一个绊脚石

我目前正在打包的项目由六个独立的块组成。现在让我们把它们叫做A、B、C、D、E和F

区块A是一组公共库和实用程序，其他项目都使用它们。它不提供任何最终用户功能

Chunk B是另一组需要Chunk A提供的功能的公共库和实用程序。这似乎有些奇怪，但我无法影响或控制该体系结构

Chunk C是第三组公共库和实用程序，它们需要Chunk a和B提供的功能。这似乎比以前更奇怪，但我仍然没有能力改变这一点

块D、E和F都需要块A、B和C提供的功能

如果可能，我希望确保只有一个区块A、B和C的安装，它们在D、E和F的安装中共享。我已经得到保证，区块A、B和C将保留稳定的API，以便在不破坏D、E或F功能的情况下升级它们

我的直接想法是为A、B和C中的组件创建合并模块，然后在D、E和F的独立安装程序提供的功能中引用它们。这将使安装程序膨胀，但可以保证安装必要的组件。不幸的是，我担心升级时会在Windows Installer验证中产生问题

我的另一个想法是为a、B和C制作一个安装程序，并通过ComponentSearch在D、E和F的安装程序中要求它

---

这两种想法都有意义吗？如果这两个想法都没有意义，你有什么正确方法的建议吗？

在每个安装程序中包含a+B+C，并安装到通用文件中。Windows Installer将处理引用计数，以便磁盘上只存在一个副本，并保留到最后一个产品被删除为止。升级就可以了，Windows Installer就是为这类事情而设计的：）

但是，我建议使用

我得到的保证是 块A、B和C将保持稳定 API，以便对其进行升级 在不破坏 D、 E，

在此处输入代码

或F

一个稳定的API可能还不够。如果应用程序意外地依赖于未记录的巧合行为（例如返回列表中项目的顺序），或者更糟的是，依赖于实际上是bug的行为，该怎么办？共享组件的升级可能会破坏您的应用程序，因为它没有针对升级的组件进行测试

我眼前的想法是创造 合并模块。。。我担心会 导致窗口内部出现问题 升级时进行安装程序验证

您可能是对的，合并模块存在可维护性问题。Microsoft不再自行分发新的合并模块。众所周知，要创建可升级的组件并仍然遵循标准是很困难的

---

我更喜欢将“共享”组件单独安装到每个应用程序的bin文件夹中。我确实为这些组件创建了一些组件，以便它们可以在应用程序安装程序之间共享。在wixlib文件中，我将组件放在a

中，如果我最初使用heat为a、B和C生成wix文件，那么我应该为我打算卷入wixlibs？片段（或无模板）的文件使用片段或模块模板吗。产品和模块添加了您可能不想要的额外内容。
<Directory Id="AppBinFolder" Name="bin">
   <Directory Id="SharedComponent1Folder" /> <!-- alias for AppBinFolder -->
   <Directory Id="SharedComponent2Folder" /> <!-- another alias -->
</Directory>