强制升级在初始安装期间修改的文件
我正在使用基于WiX的安装程序的升级function。
作为安装的一部分，我们正在安装web.config文件，然后使用自定义操作来更新文件内的连接string。
但是，当我们运行升级时，这会导致一个问题。 我们希望将RemoveExistingProducts安排在InstallFinalize之后，因为这对于不删除和重新安装未更改的文件而言是最有效的。 但是，当Windows安装程序试图确定是否应该更新它时，这留下了原始web.config文件。 由于上次修改date比创builddate更新，Windows Installer决定不更新它（请参阅Windows Installer使用的版本规则 ）。 但是我们需要更新它。
一个显而易见的解决scheme是将RemoveExistingProducts的调度更改为InstallValidate之后的调度 – 但这样效率不高，而且我不认为这会使我们有机会从现有文件迁移设置，因此我们需要这样做。
任何其他的想法？
有很多方法 – 没有一个是理想的。
1：您可以使用伴随文件强制更新有问题的文件。 如果指定的伴随文件总是得到更新，这可能是要走的路。 本质上，这意味着您将非版本化文件链接到其伴随文件的版本更新逻辑（文件一起更新）。 我从来没有在WIX中使用过这个，但是我认为就像将CompanionFile属性添加到一个File元素一样简单，并且指向你想要“版本跟随”的文件的ID。 在MSI文件里面看起来像这样：
2：您可以使用自定义操作在文件成本计算之前删除该文件 （或更好地将其重命名为备份格式）。 问题是，如果安装失败，文件将会丢失。 如果您重命名文件而不是删除，则可以将其放回以防安装程序通过回滚自定义操作失败。 有时我使用RemoveFile表删除安装文件，但根据InstallExecuteSequence中指定的顺序，这可能不起作用（删除必须发生在msi文件成本之前）。
3：然后是大锤的方法 ：设置 REINSTALLMODE = amus 强制覆盖所有文件，而不pipe版本。 我甚至不应该提到这一点，因为它是非常危险的（最终可能会覆盖系统文件，或者在较新的Windows版本中，当文件受到保护时会触发一个令人讨厌的运行时错误）。 只用于开发testing，并不认为这是一个快速修复。 它会导致比解决问题更多的问题。
作为一种变化，可接受的方法可能是将REINSTALLMODE设置为emus （replace旧的和相同的版本文件）。 如果你不想增加版本号，但是可以继续重build你的二进制文件，这可能会有所帮助，就像许多.NET一样。 我的猜测是，这将导致一系列的问题，但最显着的二进制不同，但版本相同的文件在野外，如果你使用它的公共版本 – 一个部署的气味，如果有的话。 作为QA / DEV唯一的方法，它可以工作。 但严重的是，为什么要麻烦？ 只需自动增加二进制文件的构build版本即可解决问题。
只有如果有的话。 您可以尽早使用自定义操作删除特定文件，但一定要正确处理这个问题！ 或者你可以为文件指定一个版本，所以升级规则将把它看作是用一个版本化的文件replace一个版本化的文件，但是修补程序可能会得到这个文件的错误版本。
