WiX 和共享的版本化组件

发布于 2024-08-23 01:13:37 字数 1066 浏览 5 评论 0 原文

这必须是一种常见的需求,但我在网络上几乎找不到任何对它的引用...

我有一个产品,它具有三组组件,一组安装在服务器上,一组安装在网络头上,一组安装在网络上开发者的机器。所有三套都可以安装在一台机器上,并且应该和平共处。

正如我昨天所看到的,每个组件都安装到不同的位置并且工作正常,但这只是临时的,因为一些文件、gac 程序集和注册表设置应该共享。现在我已经从共享组件中创建了一个合并模块,并且这个新的合并模块场景在理想条件下的安装过程中运行良好,并且我已经解决了单个 msi 的重大升级问题。

问题是在安装 msi 期间,当安装的 msi 中的合并模块的版本低于已安装的版本(不同的 msi)时 - 新版本会被旧版本覆盖!此外,在卸载三个 msis 中任何一个的例程时,即使其他已安装组件仍在使用共享内容,也会删除共享内容。

在大多数情况下,我理解为什么会出现这种行为,但我不明白应该如何配置安装程序,以便可以共享这些组件,而无需为共享组件提供单独的安装程序。另外,我也不想要一个大型安装程序 - 这不会很好地扩展。

我想要的是,这三个安装程序包含合并模块中在构建时可用的组件的任何最新版本。安装时,如果安装了较新版本的共享组件,请勿覆盖它们。在卸载(和升级)时,应跟踪的引用计数将确定是否应删除共享项目。

如果我遗漏了一些东西,这里是合并文件的重要部分:我的合并模块的版本号(“wxy”中的 y)随着每次构建而递增,包 ID 保持固定,并且每个组件都有 Shared="yes" (尽管我也尝试过没有这个)。

我已经开始在注册表中存储各种版本号,并且我想也许只有当注册表中的版本号不存在或更低时,我才能有条件地安装合并模块功能。但条件参数无法正确评估 wxyz,如文档所述。然后文档建议AppSearch,但AppSearchRegistrySearch只能检查是否存在,也不能比较版本号。显然 FileSearch 可以,但程序集文件版本号不会随着每次构建而增加。

我读到 MergeModules 有很多问题 - 也许这些就是问题 - 但 wixlibs 似乎也没有为这些问题提供任何解决方案。

那么进行合并模块版本控制的正确方法是什么???我在亚马逊上发现了一本书,其中有一个名为“合并模块版本控制”的目录条目,但这本书已经绝版了。 :-P

This has to be a common need yet I find hardly ANY references to it on the web...

I've got a product that has three sets of components, one installed on the server, one on the web head, and one on the developer's machine. All three sets could be installed on one machine and should peacefully coexist.

As I had it yesterday, each component was installing to a different place and working ok, but that was just temporary as some files, gac'd assemblies, and registry settings ought to be shared. Now I've made a merge module out of the shared components and this new merge-module scenario is working fine during install under ideal conditions and I've got major upgrades of a single msi all figured out.

The problem is during installation of an msi when the version of the merge module within the installing msi is lower than that of the already installed version (of a different msi) - the newer version is overwritten with the older version! Furthermore, upon un-installation routine of any of the three msis, the shared stuff is removed even though it is still in use by the other installed components.

For the most part I understand why I'm getting this behavior, but I don't understand how I'm supposed to be configuring my installers so that these components can be shared WITHOUT having a separate installer for the shared components. Also, I don't want one big installer either - this won't scale well.

What I want is that the three installers contain whatever latest version of the components in the merge module were available at build-time. At install time, if a newer version of the shared components is installed, don't overwrite them. At uninstall(and upgrade) time, the reference counts that should have been tracked would determine whether the shared items should be removed.

In case I'm just missing something, here are the important parts of the merge file: My merge module's version number (the y in "w.x.y") is incremented with each build, the package ID remains fixed, and each component has Shared="yes" (although I've tried it without this as well).

I've started storing the various version numbers in the registry, and I figured maybe I could conditionally install the merge module feature only if the version number in the registry were absent or lower. But the conditional arguments can't evaluate w.x.y.z properly, as says the documentation. The documentation then suggests AppSearch, but AppSearch RegistrySearch can only check for existence, not version number comparison either. Apparently the FileSearch can, but the assembly file version numbers will not be incremented with each build.

And I've read that MergeModules have many problems - maybe these are them - but wixlibs don't seem to offer any solutions to these problems either.

So what is the right way to do merge module versioning??? I found a book that has a TOC entry called "merge module versioning" on Amazon but the book is out of print. :-P

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

玩套路吗 2024-08-30 01:13:37

在我看来,我们想要的这种行为(始终安装共享组件的最佳版本)仅从 MSI 4.5 开始受支持。所以也许这不是WiX本身的问题,但我对WiX几乎一无所知。

我们希望在共享组件的组件表中设置属性 msidbComponentAttributesShared (0x0800)。也许您可以通过 Orca 检查您的 MSM。

我认为这篇博文提到了一些相关内容(但可能对您没有太大帮助):
http://blogs.msdn.com/windows_installer_team/archive/2008/03/29/windows-installer-4-5-servicing-enhancements-shared-components-and-patch-uninstall.aspx< /a>

It looks to me that this behaviour that we want - always have the best version of a shared component installed - is supported only from MSI 4.5 on. So maybe this is not a problem of WiX itself, but I know almost nothing about WiX.

We will want the attribute msidbComponentAttributesShared (0x0800) to be set in the Component table for the shared component. Maybe you can check your MSM with Orca for this.

I think this blog post mentions something about it (but it's probably not of great help for you here):
http://blogs.msdn.com/windows_installer_team/archive/2008/03/29/windows-installer-4-5-servicing-enhancements-shared-components-and-patch-uninstall.aspx

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文