MS Installer / Wix 中的依赖项
我目前正在学习 WiX 和 Windows 安装程序的变化，但遇到了障碍。
我当前正在打包的项目由六个离散的块组成。现在我们称它们为 A、B、C、D、E 和 F。
块 A 是一组可供所有其他项目使用的公共库和实用程序。它不提供任何最终用户功能。
Chunk B 是另一组公共库和实用程序，需要 Chunk A 提供的功能。这看起来很奇怪，但该架构超出了我影响或控制的能力。
块 C 是第三组公共库和实用程序，需要块 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 的安装程序中要求它。
这两种想法都有道理吗？如果这两个想法都没有意义，您对正确的方法有什么建议吗？
I'm currently learning the vagaries of WiX and Windows installer and I've hit a stumbling block.
The project that I'm currently packaging is made up of six discrete chunks. For now let's call them A, B, C, D, E, and F.
Chunk A is a set of common libraries and utilities that are used by every other project. It does not present any end-user functionality.
Chunk B is another set of common libraries and utilities that require functionality provided by Chunk A. This seems odd, but the architecture is beyond my ability to influence or control.
Chunk C is a third set of common libraries and utilities that require functionality provided by chunks A and B. This seems even more odd than before, but I still have no ability to change this.
Chunks D, E, and F, all require the functionality provided by chunks A, B, and C.
If possible, I would like to make sure that there is only one installation of chunks A, B, and C, that are shared across the installations of D, E, and F. I have been given the assurance that chunks A, B, and C will retain stable APIs so that they may be upgraded without breaking the functionality of D, E, or F.
My immediate thought is to create merge modules for the components in A, B, and C, then reference them in the features provided by the separate installers for D, E, and F. This would bloat up the installers, but it would guarantee that the necessary components are installed. Unfortunately, I fear that it would cause problems inside the Windows Installer validation when upgrading.
Another thought that I had was to make a single installer for A, B, and C and require it in the installers for D, E, and F via a ComponentSearch.
Does either idea make sense? If neither idea makes sense, do you have any recommendations for a correct way to do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
每个安装程序都包含 A+B+C，并安装到常用文件。 Windows Installer 将处理引用计数，以便磁盘上仅存在一个副本，并保留到最后一个产品被删除为止。升级就可以了，Windows Installer 就是为这种事情设计的:)
但是，我建议使用 Wixlibs
Include A+B+C with every installer, and install to common files. Windows Installer will handle the reference counting so that only one copy will exist on disk and remain until the last product is removed. Upgrading will be fine, Windows Installer is designed for this sort of thing :)
However, rather than Merge Modules, I suggest using Wixlibs
稳定的 API 可能还不够。如果应用程序意外依赖于未记录的巧合行为（例如顺序），该怎么办？返回列表中的项目），或更糟糕的是，实际上是错误的行为？共享组件的升级可能会破坏您的应用程序，因为它没有针对升级的组件进行测试。
您可能是对的，合并模块存在可维护性问题。 Microsoft 不再自行分发新的合并模块。创建可升级组件并仍然遵循 Windows 安装程序组件规则。
我更喜欢将“共享”组件分别安装到每个应用程序的 bin 文件夹中。我确实为这些组件创建了wixlibs，以便它们可以在应用程序安装程序。在 wixlib 文件中，我将组件放入
因此，应用程序的依赖项位于其自己的 bin 文件夹中，并且彼此保持隔离。当然，这是一个权衡：
应用程序安装程序需要
更新并重新分发，而不仅仅是共享组件的一个安装程序。
共享组件已安装
多次）。
对于 .NET 程序集，GAC、强名称、策略文件重定向等。但是这篇文章已经运行太长了:-)
A stable API may not be enough. What if an application accidentally relies on behavior which is an undocumented coincidence (such as the order of items in a returned list), or worse, on behavior which is actually a bug? An upgrade of the shared components may then break your application because it was not tested against the upgraded components.
You may be right that there are serviceability issues with merge modules. Microsoft no longer distributes new merge modules themselves. It is also notoriously difficult to create upgradeable components and still follow the Windows Installer Component Rules.
I prefer to actually install "shared" components into each application's bin folder separately. I do create wixlibs for these components, so that they can be shared between the application installers. Inside the wixlib files, I put the component in a
<DirectoryRef Id="SharedComponentFolder>. This directory reference is left undefined, which is not a problem forlit.exe. In the application installers, I then alias the application bin folder like this:As a result, the applications have their dependencies in their own bin folder and remain isolated from each other. There is a trade-off of course:
application installer needs to be
updated and redistributed, rather than just one installer for the shared component.
shared components are installed
multiple times).
With .NET assemblies, the story can become even more complicated with the GAC, strong names, policy file redirects etc. But this post is already running too long :-)