运行 RemovePreviousVersion 时 MSI 不会安装所有文件

Question

我有一个使用 WiX 版本 3 的 MSI 构建。

我们正在部署的产品的所有以前的安装程序都可以在指定的配置下正常工作（即：如果以前的版本存在，则删除，然后安装新版本） - 但是，我们构建的新 MSI当它通过“首先删除”路径运行时，不要安装所有文件。

如果我们手动删除现有安装，然后运行新版本，则所有文件都会安装 - 当我检查 Orca 中的 MSI 文件时，会显示文件和功能，并且看起来没问题。

我们尝试在打开详细和额外日志记录（/l*vx）的情况下运行，但是我们只能看到文件是否未注册& 然后安装。

有什么想法或建议吗？ 这让我们陷入困境。

Answer 1

根据默认的自定义操作顺序，Windows Installer 确定在删除任何现有版本的软件之前需要安装/覆盖哪些文件。 Windows Installer 使用 REINSTALLMODE 属性的值来告诉它如何决定何时覆盖文件。 如果REINSTALLMODE包含“o”，那么它只会安装版本不同或文件不存在的文件； 仅当文件的修改日期 <= 创建日期（即文件未修改）时，才会安装非版本化文件。 如果 REINSTALLMODE 包含“a”，则它将始终安装该文件，无论现有文件附加的任何版本或日期信息如何。

您的情况很可能发生以下情况：

1. Windows Installer 确定要安装哪些文件。 它决定不需要安装某些文件（可能是因为它们已经存在并且与 MSI 中的文件具有相同或更新的版本）。
2. 先前版本的软件将被删除，包括 Windows Installer 确定不需要安装的文件。
3. Windows 安装程序会安装新安装的文件，但不会安装它确定不需要安装的文件。

最终的结果是，升级软件后，一堆文件丢失了。 设置 REINSTALLMODE=amus 而不是 omus 可能会解决您的问题，但您应该确保您知道这将如何影响您安装的其余部分。 如果您不想覆盖任何文件，则需要将这些组件标记为“从不覆盖”。

Answer 2

好的，与我所在的其他人交谈帮助我找到了问题的解决方案。

我们添加了属性 REINSTALLMODE 并将其设置为 amus。 这是什么意思？

默认情况下，该属性设置为 omus，这意味着：如果文件丢失或较旧，则重新安装，重写计算机和用户配置单元的注册表，重新安装快捷方式。 将其更改为 amus 基本上表示：重新安装所有文件。

所以，不能 100% 确定原因是什么 - 我怀疑可能有奇怪的锁或其他东西，但设置为 amus 不会产生任何不利影响，所以我们会坚持这样做。

感谢您的建议。

（此外，可以在此处找到有关此属性的更多详细信息：MSDN：REINSTALLMODE 属性

Answer 3

您的 步骤是什么样的？ 可能是在安装后运行了removeexisting，并删除了先前版本和当前版本中相同的所有文件。

我将安装程序设置为 以确保它在其他任何操作之前完成。 我不知道这是否正确，但它似乎有效。

    <Upgrade Id="$(var.UpgradeCode)">
        <!--Upgrade code found at http://www.nichesoftware.co.nz/blog/200809/upgradable-msi-installations-with-wix -->
        <!-- Detect any newer version of this product-->
        <UpgradeVersion Minimum="$(var.version)" IncludeMinimum="no" OnlyDetect="yes" Language="1033" Property="NEWPRODUCTFOUND" />

        <!-- Detect and remove any older version of this product-->
        <UpgradeVersion Maximum="$(var.version)" IncludeMaximum="yes" OnlyDetect="no" Language="1033" Property="OLDPRODUCTFOUND" />
    </Upgrade>
    <CustomAction Id="PreventDowngrading" Error="Newer version already installed"></CustomAction>
    <InstallExecuteSequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
        <RemoveExistingProducts After="InstallInitialize" />
    </InstallExecuteSequence>
    <InstallUISequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
    </InstallUISequence>

Answer 4

我知道这是一个较旧的线程，但我遇到了解决方案未涵盖的类似问题。 就我而言，我有一个 DLL，它的版本号实际上比它的前身版本低。 此 DLL 永远不会出现在升级安装中。 运行

msiexec /i myproduct.msi /l*vx install2.log

并检查日志表明该文件从未安装。 它只是没有作为安装的文件之一出现在日志中。 MSI 肯定包含该文件，最好的证据是修复会放置该文件。 此外，使用各种工具分解 MSI 显示了该文件的存在。 直接安装在干净的机器上总是可以的。

这没有帮助：

msiexec /i myproduct.msi REINSTALL=ALL REINSTALLMODE=amus /l*vx install3.log

我正在使用 Wix 构建 MSI，并且我已经使用这个脚本很多年了。 最近我们在 5.3 版本中设置了脚本来完全删除旧目录。 这已经工作到 5.2 -> 了。 5.3和5.3→ 5.4 升级。 但在 5.5 版本中，DLL 全部用新版本的 DLL 重新构建。 DLL 项目托管在 GitHub 中。 该特定 DLL 的构建脚本被设置为“10.0.0.{git rev-list --count HEAD}”的汇编版本。 该项目已被移动，导致 HEAD 计数从 444 变为 30。wixscript

包含此内容，

define ProductGuid = "{nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}"

因此我们在每个版本上更新产品 guid（而不是产品升级 guid）。

补救措施是稍微更改此 dll 的构建脚本，将程序集版本设置为“10.0.1.{git rev-list --count HEAD}”，大概被视为更高版本编号版本。

为什么这有效，我无法解释。