Wix 在MajorUpgrade中降级文件

编辑 请看下面的小照片

我的问题与这里相同：

（主题外：Stackoverflow markdown是否支持表？在中没有提到。）

出于某种原因，我们的增量构建系统创建了虚假的版本号，有时版本号会减少。虽然我同意如果你告诉我先解决这个问题，但它不在我的控制之下，如果有人想要降级nuget软件包，同样的问题也会出现

链接问题中提到的解决方法（在成本计算之前安排）解决了原来的问题，但似乎会导致刻录和升级问题

提到的另一个解决方法是更改重新安装模式，但我使用的是Burn，afaik不允许我更改它。（我们没有共享组件，因此如果可以更改重新安装模式，这可能是最好的解决方案。）

在成本计算之前安排它之后，我有几次发现引导程序在ARP中注册了，但MSI没有安装。（我认为这是因为取消了升级，导致了新安装的回滚，但没有重新安装旧版本-但我不确定这一点）

我们通过调用Guid.NewGuid（）来生成组件Guid，因此违反了组件规则，因此我无法在InstallFinalize之后安排它，但一条注释提到MSI会保留旧的（更高版本的）版本，这绝对不是我想要的

基本上，我的MSI中有一个目录布局，并且希望将该1:1复制到所选目录中，忽略并覆盖任何现有文件，而不管其版本如何。为了解决无版本文件的类似问题，我对每个文件使用以下模式：

<Component Directory="APPLICATIONFOLDER" Permanent="no" Guid="##Guid.NewGuid()##" Id="##some random id##">
    <File Id="##some different random id##" Source="#source#" />
    <RemoveFile Id='##some other random id##' On='install' Name='#name#'/>
</Component>

如果可能，我希望在InstallInitialize之后安排RemoveExistingProducts，这样卸载就在事务内部

有没有一种干净的方法可以在主要升级过程中降级文件？尽管在花费大部分成本之前安排文件的工作环境是可行的，但我仍然不得不抑制ICE27，因为ICE27对此表示不满

编辑：
我搜索了更多，发现其中提到编译后修改文件表。我想这对我来说可能是一个可行的选择，但解决msi bug真的会那么难吗？（我认为主要升级是删除文件，而不是将它替换为bug。）< /P> EDIT2:

我创建了一个小复制，它包含6个MSI文件：

• 在具有不同GUID的中，DLL被降级，但两个版本具有不同的ID和不同的GUID
• 在具有相同GUID的中，DLL也会降级，但两个版本具有相同的（自动生成的）ID和GUID

两者表现出相同的行为：

如果安装1\SetupProject.msi，则目录包含三个文件：1.txt、1.dll和1.exe。
如果然后运行2\SetupProject.msi，则只会重新安装.txt和.exe（该.exe的版本不变）

在rep\u before\u costinitialize中，rep是在costinitialize之前安排的，主要升级工作正常，所有三个文件都在磁盘上

Edit3:
我还能够重现我的烧伤问题：
如果我在CostInitialize之前安排REP，则主要升级将按预期工作：DLL降级。
但是Burn升级的事务逻辑不再像预期的那样工作。
如果我安装了<强> SETUPEXEP\\BooTrasPopPosij.exe ，然后启动<强> Stutuxe\\\BooTrasPopPosij.exe ，但是在中间取消它，安装MSI，但是在ARP中仍然显示<强> 1 <强>的条目。

---

repo:

FWIW，我过去曾与MS支持部门谈过在成本计算之前让REP成功完成升级，当时他们说这没问题，同时指出这也是在迁移现有功能之前，因此如果您在升级过程中迁移功能，就会出现问题

我不会改变文件表。这将确保磁盘上的版本与文件表中的版本不匹配，并使该文件成为修复的候选文件。如果磁盘上的版本为2.0，而文件表中的版本为3.0，则修复将看到文件已损坏。一些主要升级或修补程序会注意到这一差异，并要求您提供源MSI以恢复文件（因为版本不匹配），然后再决定是否需要修补或升级文件。如果磁盘上的版本与文件表不匹配，Windows无法知道是否需要通过传入更新更新文件

在任何情况下，对于单个文件，只需使用Visual Studio打开该死的文件并更改真实版本就更安全、更容易了

偶尔也会出现类似这样的bug，这会使问题变得模糊

---

您是否使用代码生成该文件表键？我怀疑您的文件表密钥在不同的MSI中是不同的。这可能不是问题所在，但已知更改文件表键会在其他更新场景中导致问题。如果升级尝试使用文件表的主键（关系数据库会这样做）查找文件的早期版本，但在较旧的MSI中找不到，则结果可能不可预测

我使用wix生成msi，并且（目前）不做任何后处理。MSI单独工作后，安排它之前的成本，但它看起来像是我的引导程序，烧伤的问题。每次都会自动生成ID。我原本认为这不会是一个问题，因为installinitialize之后使用REP进行的主要升级应该是完全卸载旧版本，然后重新安装新版本。没错，但是“禁止安装”是在CostFinalize中完成的，所以它决定不在早期安装它。不是c

<Component Directory="APPLICATIONFOLDER" Permanent="no" Guid="##Guid.NewGuid()##" Id="##some random id##">
    <File Id="##some different random id##" Source="#source#" />
    <RemoveFile Id='##some other random id##' On='install' Name='#name#'/>
</Component>