安装升级版本时 Windows 7 安装程序包错误 2869
我有一个版本号为1.0.0.1的应用程序，它是旧版本1.0.0.0的升级。
当我尝试安装新版本时 1.0.0.1，当我的系统已经安装了旧版本时，我是 收到错误 2869。
但是如果我手动卸载旧版本&而不是尝试安装较新的版本，然后就安装成功了。
我更改了新版本的产品代码。但没有更改升级代码。
谁能告诉我原因并解决这个问题吗？
I have an application with version no: 1.0.0.1, which is an upgrade to the older version 1.0.0.0.
When I try to install the new version
1.0.0.1, when my system already has the older version installed, I am
getting the error 2869.
But if I uninstall the older version manually & than try to install the newer version, then it installs successfully.
I changed the product code for new version. But did not change the upgrade code.
Can anyone kindly let me know the reason and fix for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 MSI ProductVersion 属性中，使用主要升级逻辑比较版本时，只有前 3 个字段很重要。因此，在您的情况下，MSI 会将 1.0.0.1 和 1.0.0.0 视为 1.0.0。因此，FindRelatedProducts 不会将这种情况检测为升级。
我解决这个问题的方法是创建一个“打包”版本，其中使用（4096 * f3 + f4）将第三个和第四个字段组合成一个，但这将是你永远不会拥有更大的第四个字段（内部版本号）大于 4096，并且第三个字段不大于 15，因为 0xFFFF 是版本字段的最大值。
这使我们能够在各个夜间构建之间执行重大升级，而不仅仅是服务包，而不需要引导程序来实现次要升级，并且我们可以为每个构建提供新的产品代码，因此无需记住在以下情况下手动更新它：需求出现了。
In the MSI ProductVersion property only the first 3 fields are significant when comparing versions using the major upgrade logic. So in your case MSI will consider 1.0.0.1 and 1.0.0.0 to both be 1.0.0. FindRelatedProducts will therefore not detect this situation as an upgrade.
The way I approach this is to create a 'packed' version where the 3rd and 4th fields are combined into one using, say (4096*f3 + f4), but this will behove you never to have a 4th field (build number) greater than 4096, and a 3rd field no bigger than 15, since 0xFFFF is the maximum for a version field.
This allows us to perform major upgrades between individual nightly builds, not just service packs, without requiring a bootstrapper to achieve a minor upgrade, and we can have a new productcode for every build so there's no need to have to remember to update it manually when the need arises.