这必须是一个普遍需要，但我在网上几乎找不到任何引用......
我的产品有三组组件，一组安装在服务器上，一组安装在网络头上，另一台安装在开发人员的机器上。所有这三套都可以安装在一台机器上，并且应该和平共存。
正如我昨天所做的那样，每个组件都安装到不同的地方并正常工作，但这只是暂时的，因为应该共享一些文件，gac'd程序集和注册表设置。现在我已经从共享组件中创建了一个合并模块，这个新的合并模块场景在理想条件下安装期间工作正常，并且我已经完成了单个msi的主要升级。
当安装msi中的合并模块版本低于已安装版本（不同msi）的版本时，问题是在安装msi期间 - 旧版本会覆盖较新版本！此外，在三个msis中的任何一个的卸载例程中，即使它仍然被其他已安装的组件使用，共享的东西也会被删除。
在大多数情况下，我理解为什么我会遇到这种行为，但我不明白我应该如何配置我的安装程序，以便可以共享这些组件，而无需为共享组件提供单独的安装程序。此外，我也不想要一个大型安装程序 - 这不会很好地扩展。
我想要的是这三个安装程序包含在构建时可用的合并模块中的任何组件的最新版本。在安装时，如果安装了较新版本的共享组件，请不要覆盖它们。在卸载（和升级）时，应该跟踪的引用计数将决定是否应删除共享项。
如果我只是遗漏了一些东西，这里是合并文件的重要部分：我的合并模块的版本号（“wxy”中的y）随着每次构建而增加，包ID保持固定，并且每个组件有Shared="yes"（虽然我也没试过它）。
我已经开始在注册表中存储各种版本号，我想也许只有在注册表中的版本号不存在或更低时才能有条件地安装合并模块功能。但正如文档所述，条件参数无法正确评估w.x.y.z。然后文档建议AppSearch，但AppSearch RegistrySearch只能检查是否存在，而不是版本号比较。显然，FileSearch可以，但程序集文件的版本号不会随着每次构建而增加。
我已经读过MergeModules有很多问题 - 可能是这些问题 - 但是wixlibs似乎也没有为这些问题提供任何解决方案。
那么合并模块版本化的正确方法是什么？我发现一本书在亚马逊上有一个名为“合并模块版本控制”的TOC条目，但这本书绝版了。 :-P
答案 0 :(得分：1)
在我看来，我们想要的这种行为 - 总是安装了最佳版本的共享组件 - 仅支持从MSI 4.5开始。也许这不是WiX本身的问题，但我对WiX几乎一无所知。
我们希望在共享组件的Component表中设置属性msidbComponentAttributesShared（0x0800）。也许你可以用Orca检查你的男男性接触者。
我认为这篇博文提到了一些关于它的事情（但这对你来说可能没什么大帮助）： http://blogs.msdn.com/windows_installer_team/archive/2008/03/29/windows-installer-4-5-servicing-enhancements-shared-components-and-patch-uninstall.aspx