强制升级在初始安装过程中修改的文件 [英] Forcing an upgrade of a file that is modified during its initial installation
问题描述
我正在为基于WiX的安装程序开发升级功能.
I'm working on the upgrade feature for my WiX-based installer.
作为安装的一部分，我们将安装web.config文件，然后使用自定义操作更新文件中的连接字符串.
As part of the instalation, we are installing a web.config file and then using a custom action to update the connection strings inside the file.
但这在我们运行升级时会导致问题.我们希望在InstallFinalize之后安排RemoveExistingProducts，因为这在不删除和重新安装未更改的文件方面是最有效的.但是，当Windows Installer尝试确定是否应更新它时，这会将原始的web.config文件保留在原位.由于上次修改日期早于其创建日期，因此Windows Installer决定不对其进行更新(请参见版本转换规则).但是我们需要对其进行更新.
But this causes a problem when we run our upgrade. We would like to have the RemoveExistingProducts scheduled for after InstallFinalize since this is most efficient in terms of not removing and reinstalling files that have not changed. But this leaves the original web.config file in place at the time when Windows Installer is trying to determine whether it should update it or not. Since it's last modified date is more recent than its creation date, Windows Installer decides not to update it (see versioning rules that Windows Installer uses). But we need it to be updated.
一个明显的解决方案是将RemoveExistingProducts的调度更改为InstallValidate之后-但这效率低下，而且，如果我们需要这样做，我认为这不会给我们提供从现有文件迁移设置的机会.
One obvious solution is to change the scheduling of RemoveExistingProducts to after InstallValidate - but this is inefficient, and also, I don't think it would give us the opportunity to migrate settings from existing files, should we need to do that.
还有其他想法吗?
推荐答案
有很多方法-都不是理想的方法.
There are many ways - none are ideal.
1:您可以使用伴侣文件强制更新相关文件.如果指定的伴随文件始终得到更新，则可以采用这种方法.本质上，这意味着您将非版本文件链接到其伴随文件的版本更新逻辑(文件一起更新).我从未在WIX中使用过它，但我认为这就像将 CompanionFile属性添加到File元素并指向您要遵循版本"的文件的ID一样容易.在MSI文件中，它看起来像这样:
1: You can use a companion file to force update of the file in question. Provided the companion file specified always gets updated, this may be the way to go. Essentially this means that you link the non-versioned file to the version update logic of its companion file (files are updated together). I have never used this in WIX, but I think it's as easy as adding the CompanionFile attribute to a File element and point to the ID of the file you want to "version follow". Inside the MSI file it will look something like this:
2:您可以在文件成本核算之前使用自定义操作删除文件(或者更好的是，将其重命名为备份格式).问题是，如果安装失败，文件将丢失.如果您重命名文件而不是删除文件，则可以通过回滚自定义操作将其放回以防安装失败.有时我会使用RemoveFile表删除安装时的文件，但是根据InstallExecuteSequence中指定的顺序，这可能无法正常工作(必须在msi进行成本核算之前删除).
2: You can use a custom action to delete the file before file costing (or better yet, rename it to a backup format). The problem is that if the setup fails the file will be missing. If you rename the file instead of deleting you can put it back in case the setup fails via a rollback custom action. Sometimes I use the RemoveFile table to remove files on install, but depending on the sequencing specified in InstallExecuteSequence this may not work (deletion must happen before msi does file costing).
3:然后有大锤方法:设置 REINSTALLMODE = amus 以强制覆盖所有文件，无论版本如何.我什至不提这件事，因为它非常危险(您可能最终会覆盖系统文件，或者在较新的Windows版本上，由于文件受到保护，会触发讨厌的运行时错误).仅将其用于开发人员测试，不要认为这是快速解决方案.造成的问题多于解决的问题.
3: Then there is the sledgehammer approach: set REINSTALLMODE = amus to force overwrite all files regardless of version. I shouldn't even mention this since it is horribly dangerous (you can end up overwriting system files, or on newer Windows versions trigger a nasty runtime error as files are protected). Use it only for dev testing, and don't think it is a quick fix. It causes more problems than it solves.
作为一种变体，可接受的方法可能是将 REINSTALLMODE设置为emus (替换旧版本和相同版本的文件).如果您不希望增加版本号，而是继续重建二进制文件，则可能会有所帮助-就像许多.NET一样.我的猜测是，这会带来一系列全新的问题-如果您将其用于公开发行，则最明显的二进制不同但版本相同的文件在野外- >部署气味(如果有的话).但是，作为QA/DEV唯一的方法，它可以工作.但是说真的，为什么要打扰呢?只需自动增加二进制文件的构建版本，即可可靠地解决问题.
As a variation, an acceptable approach may be to set the REINSTALLMODE to emus (replace older and same version files). This can help if you don't want to increment the version numbers but keep rebuilding your binaries - as is the case in a lot of .NET. My guess is this will cause a whole new range of problems though - most significantly binary different but version identical files in the wild if you use it for public releases - a deployment smell if ever there was one. As a QA/DEV only approach it could work though. But seriously, why bother? Just auto-increment the build version of the binaries and the problem is solved reliably.
链接 :
Links:
这篇关于强制升级在初始安装过程中修改的文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
