我们使用wix来创建我们的设置 . 对于升级，我们使用this answer by Rob Mensching中演示的主要升级 . （在较新的wix版本中，您可以使用MajorUpgrade元素 . ）这通常很有效 . 删除旧产品，然后安装新产品 .
但是，显然上述内容并不完全等同于手动卸载旧产品然后手动安装新产品 .
考虑例如以下场景：
发布了我们产品的
- 版本1.0，其中包含第三方dll的5.0版本
发布了我们产品的 - 版本1.1，包含相同第三方dll的5.1版
发布了我们产品的 - 版本1.2，再次降级到第三方dll的5.0版本，因为我们发现新版本引入的问题比解决的问题多 .
显然，上面链接的wix升级逻辑，从版本1.1升级到1.2时 the 3rdparty dll will disappear . 修复是必要的，以恢复它 .
还有另一种升级方式，这适用于这种情况吗？我想我正在寻找的是升级逻辑，它允许降级组件，其行为就像手动卸载旧产品然后手动安装新产品一样 .
4 回答
我们还遇到了这样的问题，即在主要升级时没有重新安装较低版本的DLL . 我认为很奇怪安装程序会根据现有文件的版本来决定安装哪些文件，然后完全卸载所有文件，但仍然只安装在卸载旧产品之前确定要安装的文件 . 这似乎可能是Windows Installer中的一个错误......
To fix this problem we moved the RemoveExistingProducts action above the CostFinalize action.
我知道documentation on MSDN建议在
InstallValidate之后放置RemoveExistingProducts，我不确定在InstallValidate动作之前放置它是否会对次要升级产生任何负面影响，但我们决定只对我们的产品进行重大升级，因此这个解决方案似乎为我们工作 .像这样的行为通常与RemoveExistingProducts的排序有关 . 如果它发生得足够晚，Windows Installer会发现需要安装它 . 但是，当RemoveExistingProducts导致删除.dll时，没有任何内容将其删回 .
要尝试的事项包括更改RemoveExistingProducts的顺序，并在1.2包中说明.dll的版本（报告版本号高于坏版本） . 后者的缺点是对维修或修补的影响很小，因为.dll总是看起来过时 .
尝试在
InstallValidate之后安排RemoveExistingProducts，并将REINSTALLMODE属性的值更改为amus. 这样，在复制新产品的任何文件之前，旧产品将被完全删除，并且a模式将强制重新安装文件 .它是次优的，但我通过重命名第三方dll并在.wxs文件中更改与其关联的组件节点上的GUID来修复同样的问题 .