【问题标题】：WiX MajorUpgrade Schedule="afterInstallExecute" won't overwrite even non-keyPath filesWiX MajorUpgrade Schedule="afterInstallExecute" 甚至不会覆盖非 keyPath 文件
【发布时间】：2014-03-31 19:25:44
【问题描述】：

参考：http://blogs.msdn.com/b/astebner/archive/2008/10/19/9006538.aspx、http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html、http://www.joyofsetup.com/2010/01/16/major-upgrades-now-easier-than-ever/

如果我使用<MajorUpgrade DowngradeErrorMessage="A newer version is already installed." Schedule="afterInstallInitialize" />，那么安装程序几乎可以正常工作，只是在安装新产品文件之前删除了配置文件和其他所有内容。我完全明白afterInstallInitialize 指定了这种行为。

但是，如果 .config 文件已被修改（如果创建日期和修改日期不同），我想保留它，所以我将其设置为 keyPath='yes' 并尝试将 RemoveExisingProducts 安排在引用计数之后增加了Schedule='afterInstallExecute'。

但是当我使用afterInstallExecute 时，它在升级过程中的行为与我预期的不同（作为全新安装工作正常）。不会覆盖未标记为keyPath='yes'（其他所有内容）的文件的新版本，所有现有文件都保持不变，就像它们的旧版本一样。安装程序认为它无论如何都是成功的。

我的 wix 中的每个文件都有自己的组件，例如：

<Component Id="Host" Guid='*' Win64='yes'>
    <File Source='$(var.root)MyLib.dll' />
</Component>

还有：

<Product Id="$(var.productCode)" Language="1033" 
    Version="$(var.version)" UpgradeCode="$(var.upgradeCode)">
    <Package Id="*" InstallerVersion="405" Compressed="yes" Platform="x64"
        InstallPrivileges="elevated" InstallScope="perMachine" />

我正在使用 WiX 3.8 和 Burn 引导程序，但如果我在没有引导程序的情况下运行 msi，则没有任何变化。 InstallerVersion="405" 与 200 没有区别。

我没有看到“如果已安装则跳过”之类的条件。

我还应该寻找什么？是我描述的预期行为吗？

谢谢！

注意：我的产品版本的格式为0.0.238，并随着每次构建而递增。所以这应该没问题，我只使用前三个版本的组件。

以下是我的日志文件中的一些亮点：

Allowing installation of component: {...} even though a modified unversioned keyfile exists and file versioning rules would disable the component
... Won't Overwrite; Won't patch; Existing file is unversioned but modified (for my one .config file. CORRECT!)
... Won't Overwrite; Won't patch; Existing file is of an equal version (mostly for DLLs and EXEs)
... Won't Overwrite; Won't patch; Existing file is unversioned and unmodified - hash matches source file (mostly for PDBs and XML)

如果我指定-sf 链接器选项，可能会强制文件版本号与产品的整体版本号匹配（就Windows Installer 而言），则GAC 安装将失败并显示"Unknown table 'MsiAssemblyName' in SQL query: SELECT Value FROM MsiAssemblyName"。所以-sf 可能不是正确的把戏。

我认为我想避免在每次构建时更新 .NET 程序集版本号，只要接口不更改并且它们只是错误修复。这将使安装机器上的更换更加自动化，对吗？我什至不确定是否需要更改程序集版本，但无论如何我都在与它作斗争。 :-)

【问题讨论】：

如果您正在设置自定义 REINSTALLMODE 值，请检查日志：msdn.microsoft.com/en-us/library/aa371182(v=vs.85).aspx。尝试在命令行中添加 REINSTALLMODE=emus 以进行升级。

标签： wix windows-installer burn

【解决方案1】：

我读到这里有点困惑，但如果您遵循组件创建规则，您可以在 InstallFinalize 之后移动 RemoveExistingProducts。从新版本安装新文件后，这将删除旧版本。这仅在组件引用正确时才能正常工作，但会保留更改的文件。

在 InstallExecuteSequence 的早期插入 RemoveExistingProducts 将完全删除旧版本，然后重新安装所有文件 - 如果它们未在以前的版本。我认为我在 InstallExecute 之后从未使用过该职位 - 我认为您可能混淆了名称。

【讨论】：

MajorUpgrade 引用了afterInstallExecute。这些文档解释了为什么我不想等到 InstallFinalize 之后 - 然后它就退出了事务。此外，据我了解，MajorUpgrade 实际上会为您重新安排它（使用Schedule 属性），并且使用其他一些机制是错误的。我不使用permanent，只使用keyPath，它应该在覆盖之前检查修改。我希望新版本会覆盖旧版本，但当 keyPath 为 false 时不会覆盖
Guid='*' 在组件元素中？我没有使用此 Wix 功能，但如果这会更改每个构建的 GUID，那么这将破坏所有组件引用并导致此文件替换问题。在这里查看我的答案：stackoverflow.com/questions/1405100/…
获取详细日志并查看发生了什么。乍一看一切正常，如果您使用的是 WiX 主要升级元素，则 REP 将在 InstallFinalize 之前完成。请注意，文件的覆盖并不是专门与密钥文件有关，它更多的是增加您要更新的二进制文件的每个文件版本，这是在后期 REP 期间应用的文件覆盖规则的一部分。
您需要增加文件版本以在补丁期间或在最后使用 REP 升级期间更新它们。这不是 WiX 的东西，它是您构建文件时文件中的版本。对于与程序集版本不同的程序集 - 请参阅 assemblyfileversion 以在不更改程序集版本的情况下增加文件版本。如果升级正在删除程序和功能中的旧条目，则升级正在运行，并且日志中的文件复制日志条目应该说明文件正在被覆盖，因为传入的文件具有更高的版本。
我认为他应该可以使用 REINSTALLMODE=emus。