WiX 升级问题 - 文件的主要版本已增加,但修订版较低,现在旧文件已删除,但升级期间不会复制新文件

发布于 2024-11-27 10:15:21 字数 2212 浏览 0 评论 0原文

我根据目录自动为我的安装程序生成一个 WiX 文件(用于 Web 应用程序),它包含对以下 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 库更新为新的内部版本,版本号和程序集标题/描述属性发生了变化来自(从 Orca 转储出来)

  • 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|迁移器。提供商.dll 79872 3.2.0.1 0 512 57

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

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

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

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

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

I automatically generate a WiX file for my installer based on a directory (it's for a web app), and it includes references to the following 3 .Net assemblies:

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

And here is the generate WiX fragments:

<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>

We have been using the same basic installer structure for a year or so, but recently we updated the Migrator.Net libraries to a new in-house build that saw the version numbers and assembly title/description attributes change from (dumped out of Orca)

  • 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

To, after upgrading the libraries:

  • 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

Though the minor version is higher, the revision is now 1 instead of 1317.

Since then we have found that upgrading to the new version results in these 3 files not being copied (so the upgrade process removes the old files, but does not install the new files).

Would this be related to the version number of the assemblies changing, and if so is there any way to override this behavior (we just want to remove everything, then copy everything fresh, regardless of version).

Interestingly if you install, then re-run the installer and do a "repair" it does copy the new files across - I assume this is because when repairing the file is no longer there, so the file version check logic doesn't apply?

Any hints as to both how this works, and how to avoid the upgrade issue we are having would be greatly appreciated.

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

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

发布评论

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

评论(1

晨与橙与城 2024-12-04 10:15:21

正如链接的问题所示,您可以尝试重新安排 RemoveExistingProducts 以便在安装任何新文件之前删除旧产品,如下所示:

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

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

As the linked question suggests, you can try to re-schedule RemoveExistingProducts so that the old product is removed before any new files are installed, like this:

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

Another option is to modify REINSTALLMODE property, and replace e mode with a, that means its value would be amus. This way all the files will be re-installed, the operation would take longer but rather more reliable.

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