Microsoft Installer：是否可以在不更改版本号的情况下升级产品？
我们希望使用流行的 major.minor.update.build_number 版本控制方案。我们的下一个产品更新将是版本 1.0.1。
我们的内部配置管理机制生成发布版本和每日版本，所有这些都会自动打包为 MSI。开发人员和 QA 定期下载构建并更新测试设备以验证错误修复等。
每个 CM 构建都会增加 build_number 字段，因此构建版本可能看起来像这样
1.0.1.001 // Release build
1.0.1.002 // Daily build
1.0.1.003 // Another Daily build
1.0.1.004 // New Release build
我们的问题是，因为我们的 ProductVersion 不会改变，Microsoft 的安装程序技术不会让我们在测试设备上将这些 MSI 作为更新运行。我们必须完全卸载现有产品并重新安装所需的 MSI。
有没有办法编写我们的 MSI 以应用更新，而不管 ProductVersion 标记如何？
我们使用InstallShield。是否有替代安装技术可以让我们做我们想做的事？
谢谢！
We want to use the popular major.minor.update.build_number versioning scheme. Our next product update will be version 1.0.1.
Our in-house Config Management mechanism produces Release builds and Daily builds, all of which are automatically packed as MSI's. Developers and QA regularly download builds and update test rigs with them to verify bug fixes etc.
Each CM build increments the build_number field, so build versions might look something like this
1.0.1.001 // Release build
1.0.1.002 // Daily build
1.0.1.003 // Another Daily build
1.0.1.004 // New Release build
Our problem is that, because our ProductVersion doesn't change, Microsoft's Installer technology won't let us run those MSI's as updates on our test rigs. We have to completely uninstall the existing product and reinstall the desired MSI.
Is there a way to author our MSI's to apply updates regardless of the ProductVersion stamp?
We use InstallShield. Is there an alternative installation technology that would allow us to do what we want?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在这种情况下，您应该能够进行较小的升级。如果您的目标是进行重大升级，则应该更改 ProductVersion 属性的前三个字段之一。
如果您的目标是逆流而上，那么您需要在 FindRelatedProducts 和 RemoveExistingProducts 之间插入自定义操作，以覆盖 MSI 的内置产品检测逻辑。基本上，您需要使用 Msi API 来查找您的 UpgradeCode 的已安装 ProductCode。
我个人推荐
Major.Minor.Build.Patch 所以我的增量构建序列是
1.0.1.0
1.0.2.0
1.0.3.0
1.0.4.0
1.1.5.0
1.1.6.0
1.1.7.0
.0 使我能够灵活地重建程序集并在需要时将它们作为补丁提供。
You should be able to do a minor upgrade in this situation. If your goal is to do major upgrades, you should be changing one of the first three fields of the ProductVersion property.
If your goal is to swim upstream then you'll need a custom action inserted between FindRelatedProducts and RemoveExistingProducts to override MSI's built-in product detection logic. Basically you'll want to use the Msi API to find installed ProductCodes for your UpgradeCode.
Personally I reccomend
Major.Minor.Build.Patch so my incremented build sequence is
1.0.1.0
1.0.2.0
1.0.3.0
1.0.4.0
1.1.5.0
1.1.6.0
1.1.7.0
The .0 allows me flexibility to rebuild assemblies and ship them as patches if needed.