Product元素中的Upgrade元素，结合适当的操作调度，将执行您所需要的卸载。确保列出所有要删除的产品的升级代码。

<Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" />
<Upgrade Id="00000000-0000-0000-0000-000000000000">
  <UpgradeVersion Minimum="1.0.0.0" Maximum="1.0.5.0" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" IncludeMaximum="no" />
</Upgrade>

请注意，如果您对构建非常谨慎，就可以防止人们意外地安装较旧版本的产品而不是较新的版本。这就是Maximum字段的作用。当我们构建安装程序时，我们将UpgradeVersion Maximum设置为正在构建的版本，但是IncludeMaximum="no"以防止这种情况。

您可以选择有关RemoveExistingProducts的调度。我更喜欢把它安排在InstallFinalize之后(而不是其他人推荐的InstallInitialize之后):

<InstallExecuteSequence>
  <RemoveExistingProducts After="InstallFinalize"></RemoveExistingProducts>
</InstallExecuteSequence>

在复制新文件和注册表项之前，将一直安装以前版本的产品。这让我可以将数据从旧版本迁移到新版本(例如，您已经将用户首选项的存储从注册表切换到XML文件，但是您希望礼貌地迁移他们的设置)。这个迁移是在InstallFinalize之前的一个延迟自定义操作中完成的。

另一个好处是效率:如果有未更改的文件，当你在InstallFinalize之后调度时，Windows安装程序不会费心再次复制它们。如果在InstallInitialize之后进行调度，则会首先完全删除以前的版本，然后安装新版本。这会导致不必要的删除和重新复制文件。

有关其他调度选项，请参阅MSDN中的RemoveExistingProducts帮助主题。本周的链接是:http://msdn.microsoft.com/en-us/library/aa371197.aspx

我建议你看看Alex Shevchuk的教程。他在《从MSI到WiX，第8部分-主要升级》中用一个很好的实例解释了通过WiX进行的“重大升级”。

下面的内容对我很有用。

<Product Id="*" Name="XXXInstaller" Language="1033" Version="1.0.0.0" 
    Manufacturer="XXXX" UpgradeCode="YOUR_GUID_HERE">
<Package InstallerVersion="xxx" Compressed="yes"/>
<Upgrade Id="YOUR_GUID_HERE">
    <UpgradeVersion Property="REMOVINGTHEOLDVERSION" Minimum="1.0.0.0" 
        RemoveFeatures="ALL" />
</Upgrade>
<InstallExecuteSequence>
    <RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>

请确保“产品”中的“升级码”与“升级”中的“Id”匹配。

Product元素中的Upgrade元素，结合适当的操作调度，将执行您所需要的卸载。确保列出所有要删除的产品的升级代码。

<Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" />
<Upgrade Id="00000000-0000-0000-0000-000000000000">
  <UpgradeVersion Minimum="1.0.0.0" Maximum="1.0.5.0" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" IncludeMaximum="no" />
</Upgrade>

请注意，如果您对构建非常谨慎，就可以防止人们意外地安装较旧版本的产品而不是较新的版本。这就是Maximum字段的作用。当我们构建安装程序时，我们将UpgradeVersion Maximum设置为正在构建的版本，但是IncludeMaximum="no"以防止这种情况。

您可以选择有关RemoveExistingProducts的调度。我更喜欢把它安排在InstallFinalize之后(而不是其他人推荐的InstallInitialize之后):

<InstallExecuteSequence>
  <RemoveExistingProducts After="InstallFinalize"></RemoveExistingProducts>
</InstallExecuteSequence>

在复制新文件和注册表项之前，将一直安装以前版本的产品。这让我可以将数据从旧版本迁移到新版本(例如，您已经将用户首选项的存储从注册表切换到XML文件，但是您希望礼貌地迁移他们的设置)。这个迁移是在InstallFinalize之前的一个延迟自定义操作中完成的。

另一个好处是效率:如果有未更改的文件，当你在InstallFinalize之后调度时，Windows安装程序不会费心再次复制它们。如果在InstallInitialize之后进行调度，则会首先完全删除以前的版本，然后安装新版本。这会导致不必要的删除和重新复制文件。

有关其他调度选项，请参阅MSDN中的RemoveExistingProducts帮助主题。本周的链接是:http://msdn.microsoft.com/en-us/library/aa371197.aspx

您最好在WiX-users邮件列表中询问这个问题。

WiX最好在充分理解Windows安装程序的情况下使用。你可以考虑获得“Windows安装程序权威指南”。

删除现有产品的操作是RemoveExistingProducts操作。因为它所做的事情的结果取决于它的计划位置——即，失败是否导致旧产品重新安装，以及是否再次复制未更改的文件——您必须自己计划它。

RemoveExistingProducts processes <升级当前安装中的>元素，将@Id属性匹配到系统上所有已安装产品的UpgradeCode(在<Product>元素中指定)。UpgradeCode定义了一系列相关产品。任何具有此UpgradeCode的产品，其版本落在指定的范围内，且UpgradeVersion/@OnlyDetect属性为no(或省略)，将被删除。

RemoveExistingProducts的文档提到了设置UPGRADINGPRODUCTCODE属性。这意味着要移除的产品的卸载过程接收到该属性，其值是正在安装的产品的product /@Id。

如果您的原始安装不包括升级码，您将无法使用此功能。

我阅读了WiX文档，下载了示例，但在升级时仍然有很多问题。次要升级不执行以前产品的卸载，尽管有可能指定这些卸载。我花了一天多的时间进行调查，发现WiX 3.5引入了一个用于升级的新标签。用法如下:

<MajorUpgrade Schedule="afterInstallInitialize"
        DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit." 
        AllowDowngrades="no" />

但是问题的主要原因是文档中说要在小升级和小升级中使用“重装=ALL REINSTALLMODE=vomus”参数，但它并没有说这些参数在大升级中是禁止的——它们只是停止工作。所以你不应该在重大升级时使用它们。