代码之家  ›  专栏  ›  技术社区  ›  Tom Corelis

用WiX和C管理依赖地狱#

  •  4
  • Tom Corelis  · 技术社区  · 14 年前

    我们正处于产品发布的前夕,在最后一刻,我收到了大量的崩溃报告,这些报告似乎与我们的安装程序有关,这是一个WiX3项目,对x86和x64版本有单独的输出。这些问题一直困扰着我 都修好了,却发现他们还在潜伏。

    该产品本身是通过.NETRemoting相互通信的二进制文件的集合,包括一个Windows服务和一个小COM组件,该组件作为插件加载到另一个应用程序中。服务作为系统运行,COM块在低权限上下文中运行,而其他块在正常用户上下文中运行。其他部分包括第三方COM对象库DLL和带有.net远程处理接口的共享DLL。

    我观察到MSI的怪异行为,特别是在版本升级方面。在MS的anal强名称实现之间(特别是加载给定程序集之前的精确版本检查), 一个有文档记录的WiX/MSI bug,在升级时看到关键文件被删除(基本上,如果升级MSI中的文件与现有安装的版本号相同,则该文件将被删除) (编辑:在制作上述文档时遇到问题……),并且必须解决Wow64虚拟化问题(x86 MSI只能通过Wow64写入注册表/HD位置,但是x64 MSI不能在x86计算机上运行……),我准备将整个内容丢弃并将其移植到另一个安装系统。

    我所寻找的技巧+技巧,技术,或建议如何正确地做的事情,使我不与WindowsInstaller扭曲的逻辑意识斗争。 我厌倦了与WiX/MSI/Windows安装程序战斗。它所需要做的就是把文件和注册表项放在我告诉它的地方,在适当的时候升级它们,并且在用户卸载之前不要删除任何东西。相反,依赖项会被随意删除,从而产生一大堆不可跟踪的异常(不能包装 try{} 阻塞函数声明)和GPF'ing整个应用程序。

    我对共享DLL和依赖DLL的“最佳实践”和示例以及确保 如果 一个文件需要交给GAC

    谢谢!

    汤姆

    3 回复  |  直到 14 年前
        1
  •  3
  •   saschabeaumont    14 年前

    从阅读开始 The Definitive Guide to Windows Installer

    如果你不 希望 Windows Installer的可靠性和弹性,或者如果您试图以任何方式绕过它,那么请使用其他方法。WindowsInstaller所做的不仅仅是“把文件和注册表项放在我告诉它的地方”。

    . 从开发的角度来看,这是最难理解的概念,您不能仅仅编辑一个配置文件或编写更多的数据并期望它能够持久存在。一旦你了解了这一点,Windows安装程序就成了小菜一碟,你设计的程序和功能就可以在它的限制范围内工作,而不是试图摆脱它们:)

    其他一些有用的链接。。。

        2
  •  1
  •   Louis de la Verité William Shurtleff    9 年前

    假设您至少使用wix3.0,那么可以使用MakeSfxCA.exe将依赖项打包到单个DLL中(这是DFT-部署工具基金会的一个附加内容。基本上,通过确保项目正在复制依赖的DLL开始。创建CustomAction.config文件。使用简单的.bat文件进行测试,如:

    “%WIX%\SDK\x86\sfxca.dll”^ %cd%\Managed\u custom\u action.dll^ %cd%\Dependent2.dll^ %cd%\Microsoft.Web.Administration.dll^ %cd%\Microsoft.Deployment.WindowsInstaller.dll^

    一旦成功,转换为生成后事件: $(TargetDir)\Managed\u custom\u action\u pkg.dll^ $(TargetDir)\Managed\u custom\u action.dll^ $(TargetDir)\Dependent2.dll^ $(TargetDir)\Microsoft.Web.Administration.dll^

    <Binary Id=“Managed\u custom\u action\u CA\u dll”SourceFile=“$(var.Managed\u custom\u action.TargetDir)$(var.Managed\u custom\u action.TargetName)\u pkg.dll”/>

    对于CustomAction.config,您可以在网上找到示例,例如

    这是我在处理托管代码时发现的最好的方法。

        3
  •  -1
  •   Christopher Painter    14 年前

    我有点害怕进入这一步,但局限性是只有当你没有遵循最佳实践上游。

    构建一个:

    构建B: 文件1:1.0.0.0

    现在你要做一个大的升级,在那里你已经删除了现有的产品计划后,成本确定。FindRelated Products检测到要删除的产品代码,Costing说哦,我看到我有1.0.0.0,但1.0.0.0已经安装,所以我在这里什么都不做,然后RemoveExistingProducts出现并删除旧版本,从而删除文件1。

    我一直在解决这个问题,在微软建议之前,我就计划删除现有的产品。它已经为我工作了很多年了。

    至于dependency hell,我管理一个软件产品线,它由数百个merge模块表示的数百个特性和几十个安装程序在几十个不同的feature、integration、main、maintenance和maintenance\u integ分支上消耗的数千个文件(15000+)组成。

    我该怎么做?一次一个片段和大量的自动化、SCM和虚拟机,以确保一切都按预期的方式工作。

    因为离你的产品发货这么近,我能真正提供给你的唯一“答案”就是让你知道像我这样的人总是可以被雇佣的。你会惊讶于我们中的一些人能以多快的速度将项目转过来并获得软件交付。