wix主要升级未安装所有文件

我有一个非常简单的WiX项目（版本3.7），它安装了一些文件（一个.NET程序版本6.0.0.0）。我准备使用WiX中的MajorUpgrade功能发布新版本6.0.1.0

我在Product元素中保持升级代码不变，并将版本从6.0.0.0更改为6.0.1.0

<Product Id="*" Name="MyApp" Version="6.0.1.0" Manufacturer="Me" 
       UpgradeCode="$(var.TheUpgradeCodeGUID)">

在安装了6.0.0.0的机器上，我运行了新的安装程序

删除旧版本6.0.0.0运行正常（将删除所有已安装的文件），但当安装程序继续安装新版本时，将丢失2个文件：未重新安装第三方DLL和第三方EXE（未更改）

<Component Id="AutomaticUpdaterWPF.dll" Guid="*">
        <File Id="AutomaticUpdaterWPF.dll" Source="AutomaticUpdaterWPF.dll" KeyPath="yes" Checksum="yes" />
</Component>
<Component Id="wyUpdaterProgram" Guid="*">
        <File Id="wyUpdaterProgram" Source="wyUpdate.exe" KeyPath="yes" Checksum="yes" />
</Component>

在主要升级期间，中的所有其他文件（一些已修改，一些未修改，包括其他第三方DLL）都已正确安装

如果在主要升级后单击“修复”，则会重新显示2个丢失的文件。 另外，如果我第一次安装版本6.0.1.0（没有升级，但是第一次安装在干净的机器上），那么这两个文件将直接正常安装。 （在多台Windows计算机（XP、7和8）上测试）

---

任何人有什么建议吗？以及如何修复它？

一个日志文件会有所帮助。我的猜测是，这是基于您计划删除现有产品的位置。我见过这样的情况，即成本计算发现正在安装的文件与已安装的文件相同，并决定不安装该文件。然后发生重大升级，您可以最终没有该文件。修复工作正常，因为该文件不存在，并且需要安装该文件。

提供的日志文件显示，计算机上已经存在一些文件的较新版本：

<Component Id="AutomaticUpdaterWPF.dll" Guid="*">
        <File Id="AutomaticUpdaterWPF.dll" Source="AutomaticUpdaterWPF.dll" KeyPath="yes" Checksum="yes" />
</Component>
<Component Id="wyUpdaterProgram" Guid="*">
        <File Id="wyUpdaterProgram" Source="wyUpdate.exe" KeyPath="yes" Checksum="yes" />
</Component>

MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {015A4DC1-56F4-562B-96B5-B3BE0D45FA5F} since the same component with higher versioned keyfile exists
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {4B6A1404-3892-5BEF-AB47-8FE3149211A4} since the same component with higher versioned keyfile exists

我在过去见过这个更新程序的这个问题。克里斯托弗是正确的。更新程序更新了它的文件，但没有告诉MSI（它没有更新MSI，这不是正确的做法）。新的MSI认为机器上有更新的东西，选择不安装它的文件，但在升级过程中，旧的包会删除这些文件（没有注意到版本较新）。由于新安装程序选择不安装文件，因此在修复之前，您将一无所获

若要解决此问题，您需要稍后移动RemoveExistingProducts操作。如果您使用的是MajorUpgrade元素，则

Schedule='afterInstallExecute'

或

Schedule='afterInstallFinalize'

应能解决此问题。您需要更加小心操作

---

此外，第三方供应商IMHO不应更新MSI之外的文件。他们的决定迫使您的产品采用特定的升级方式。

在旧版本的Windows Installer上，此问题记录在此处：

---

受影响产品列表显示，MSI engine 4.0及更高版本中已修复该问题。如果适用于操作系统版本，则在安装前使用4.5可再发行版本应该会有所帮助。

安装程序5.0上仍然存在错误，仍然是个问题。 在

InstallFinalize

之后放置

RemoveExistingProduct

的变通方法对我们来说不是解决方案。我在单个文件上强制执行了“按属性更新”设置

---

这个解决方案现在对我们有效。

我有另一个解决方案来解决这个问题，但之前的答复肯定为我指明了正确的方向。我的.NET项目中的DLL被分配的版本号比我以前安装的版本号低。转到AssemblyInfo.cs文件并将第三个八位字节从0增加到1解决了这个问题。Wix now将DLL识别为较新的

[assembly: AssemblyVersion("1.0.1.*")]

---

我也遇到过同样的问题。这里的问题是，在进行主要升级时，msi首先检查要安装的组件（所有版本低于已安装版本的DLL都标记为“不安装”），然后删除已安装的应用程序，然后安装新版本，但没有以前标记的组件

由于“不允许安装（…）”是在成本计算阶段完成的，并且只能在安装阶段计划主要升级，因此重新安排代表的时间没有帮助

我的解决方案是在wxs文件中将REINSTALLMODE属性设置为“amus”

<Property Id="REINSTALLMODE" Value="amus" />

---

“a”表示所有DLL都将重新安装，尽管它们的版本不同。

您是否尝试过使用详细日志记录运行安装，以了解它们未被安装的原因？安装日志文件在这里：安装日志文件在这里：（希望这有帮助）是的，它会有帮助。不过我的猜测通常是正确的。：）嗨，Rob，感谢您的分析。您的解决方案很有效！而且，您为我指出了问题根本原因的正确方向。在生成机器上，AutomaticUpdater.dll实际上自动更新到了比我在其上创建新生成/安装的开发机器上更高的版本。结果是与您描述的一模一样。您的解决方案有效&在将开发机器升级到与构建机器相同版本的第三方工具后，我也可以解决该问题。这对我来说是未来需要非常小心的事情。我在大陆航空公司（Continental Airlines）看到过很多此类问题，在那里我们生产的应用程序都是最初使用诸如SMS/Wise之类的工具部署，应用程序团队在官方送货车之外进行自己的自动更新。我必须进行“强制卸载”清理MSI的基线，然后击败应用程序团队的自动更新反模式，最终关闭MSI循环。Champion！谢谢Rob，毫无疑问为我节省了数小时（天？）的心痛。有人知道如何在Visual Studio安装项目中解决此问题吗？（.vdproj文件）。这刚刚开始发生在我身上（使用类似项目3年以上）你是怎么做到的？这个链接已经失效了