【问题标题】:WiX upgrade question - file's major version was incremented, but revision is lower, now old file removed, yet new file is not copied during upgradeWiX 升级问题 - 文件主要版本增加,但修订版本较低,现在旧文件已删除,但升级期间未复制新文件
【发布时间】:2011-10-15 18:31:13
【问题描述】:

我会根据目录(用于 Web 应用程序)为我的安装程序自动生成一个 WiX 文件,其中包含对以下 3 个 .Net 程序集的引用:

  • Migrator.dll
  • Migrator.Framework.dll
  • Migrator.Providers.dll

这里是生成的 WiX 片段:

<Fragment>
<DirectoryRef Id="bin">
  <Component Id="bin.Migrator.dll" Guid="*">
    <File Id="bin.Migrator.dll" Name="Migrator.dll" KeyPath="yes" Source="..\WebApplication\bin\Migrator.dll" />
  </Component>
</DirectoryRef>
</Fragment>
<Fragment>
<DirectoryRef Id="bin">
  <Component Id="bin.Migrator.Framework.dll" Guid="*">
    <File Id="bin.Migrator.Framework.dll" Name="Migrator.Framework.dll" KeyPath="yes" Source="..\WebApplication\bin\Migrator.Framework.dll" />
  </Component>
</DirectoryRef>
</Fragment>
<Fragment>
<DirectoryRef Id="bin">
  <Component Id="bin.Migrator.Providers.dll" Guid="*">
    <File Id="bin.Migrator.Providers.dll" Name="Migrator.Providers.dll" KeyPath="yes" Source="..\WebApplication\bin\Migrator.Providers.dll" />
  </Component>
</DirectoryRef>
</Fragment>

一年左右我们一直在使用相同的基本安装程序结构,但最近我们将 Migrator.Net 库更新为一个新的内部构建,它看到版本号和程序集标题/描述属性从 (dumped out逆戟鲸)

  • bin.Migrator.dll bin.Migrator.dll Migrator.dll 16384 3.0.1317.0 0 512 78
  • bin.Migrator.Framework.dll bin.Migrator.Framework.dll pi0mozkr.dll|Migrator.Framework.dll 20992 3.0.1317.0 0 512 79
  • bin.Migrator.Providers.dll bin.Migrator.Providers.dll jq05waoy.dll|Migrator.Providers.dll 73216 3.0.1317.0 0 512 82

升级库后:

  • bin.Migrator.dll bin.Migrator.dll Migrator.dll 16384 3.2.0.1 0 512 55
  • bin.Migrator.Framework.dll bin.Migrator.Framework.dll pi0mozkr.dll|Migrator.Framework.dll 28160 3.2.0.1 0 512 56
  • bin.Migrator.Providers.dll bin.Migrator.Providers.dll jq05waoy.dll|Migrator.Providers.dll 79872 3.2.0.1 0 512 57

虽然次要版本更高,但现在的修订版本是 1 而不是 1317。

从那以后我们发现升级到新版本会导致这3个文件没有被复制(所以升级过程会删除旧文件,但不会安装新文件)。

这是否与程序集的版本号更改有关,如果是,是否有任何方法可以覆盖此行为(我们只想删除所有内容,然后复制所有内容,无论版本如何)。

有趣的是,如果您安装,然后重新运行安装程序并进行“修复”,它确实会复制新文件 - 我认为这是因为修复文件时不再存在,因此文件版本检查逻辑不存在不申请?

任何有关其工作原理以及如何避免我们遇到的升级问题的提示将不胜感激。

【问题讨论】:

  • 在这里找到了一个类似的问题:stackoverflow.com/questions/4227456/…(略有不同的场景)-但仍然是同样的问题,您如何在不更改程序集版本的情况下解决此问题。

标签: wix windows-installer upgrade wix3


【解决方案1】:

正如the linked question 建议的那样,您可以尝试重新安排RemoveExistingProducts 以便在安装任何新文件之前删除旧产品,如下所示:

<InstallExecuteSequence>
    <RemoveExistingProducts After="InstallValidate" />
    <!-- other actions -->
</InstallExecuteSequence>

另一种选择是修改REINSTALLMODE 属性,并将e 模式替换为a,即其值为amus。这样所有文件都将重新安装,操作时间会更长,但更可靠。

【讨论】:

  • 更改事件顺序对我来说不是一个选项,但更改 REINSTALLMODE 正是我想要的 - 升级期间的安装时间对我们来说真的不是问题,我们只是想确保所有文件安装正确。
  • 这个答案没有帮助。在 InstallValidate 之后建议的 RemoveExistingProducts 位置没有帮助。将 REINSTALLMODE 设置为 amus 非常危险,因为强制重新安装所有文件,包括您可能不想降级的共享系统文件。例如,假设您有一些安装系统运行时 DLL 的合并模块。这些 DLL 稍后会由供应商使用安全补丁进行修补。当您的软件包稍后使用 amus 安装时,您将覆盖来自供应商的更新、更安全的 DLL。
  • 如图所示重新安排RemoveExistingProducts 不能解决问题。在计算成本期间(之前 RemoveExistingProducts),MSI 发现存在较新版本,并跳过该文件。你会在日志中看到Disallowing installation of component: XXX since the same component with higher versioned keyfile exists
猜你喜欢
  • 2018-02-03
  • 1970-01-01
  • 1970-01-01
  • 2017-12-27
  • 2012-03-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多