我们有一个用 Visual Studio 2005 Installer 编写的安装程序解决方案；调用 C# 自定义操作，我们遇到了一个已知问题，即在升级时运行旧安装代码而不是新代码，因为 Windows 正在运行自定义操作 dll 的缓存版本。我们知道这一点，虽然没有过分关注它——我们已经继续前进了。
当我们发布安装程序的新版本并且用户运行它时，我们现在希望它检查是否安装了更早的版本 - 如果有的话；我们想显示一条消息，告诉他们必须通过添加/删除程序删除旧版本。我们知道，如果他们先手动卸载然后再安装，那么一切都很好——但不管我们通过文档告诉用户多少次；这就是他们必须做的——他们仍然会尝试运行新的安装程序，而不是先删除旧版本。
因此，我们想发布一条信息，从而迫使他们听从他们被告知的内容！我见过一些安装程序这样做（当然不确定使用什么安装程序包来创建这些）。我们只有 VS 2005，当然还有 orca ！！
干杯，
克里斯。
这可以通过自定义启动条件来完成：
例如，如果搜索属性为 OLD_VERSION，则启动条件可能如下所示：
健康）状况：NOT OLD_VERSION
描述：An older version was found. Please uninstall it using "Programs and Features" in Control Panel.
当 OLD_VERSION 属性设置为一个值（找到旧版本）时，此启动条件将显示消息并停止安装过程。
这完全没有意义。您是否记得在新设置中更改包 GUID？包 GUID 标识特定的安装文件，如果两个 MSI 文件具有相同的 GUID，则无论它们是否相同，它们都将被视为同一个文件。这可能会触发要调用的 MSI 的缓存版本，并且各种地狱都会崩溃。
我建议阅读“重大升级”，这将允许在安装新版本之前自动卸载现有版本。您还需要确保在部署到野外之前了解该技术的基础知识。您绝不能对任何 MSI 文件使用相同的包 GUID。它实际上总是错误的，并且会导致非常神秘的问题。
我不能在这里写出整个主要的升级解决方案，但基本上它涉及创作你的 MSI 的“升级”表来检测要卸载的版本。您需要更改包代码、产品代码和版本号（仅 3 位重要）并保持相同的升级代码（具有相同升级代码的两个 MSI 文件“知道”它们是相关的 - 即它们来自同一个产品系列） . 查看 MSDN 以获取主要升级的示例。
注意！如果您已将具有重复包 GUID 的 MSI 文件部署到您的开发人员计算机，则它可能存在必须使用 MSIZap 或类似工具清理的杂散安装。谨慎使用，或者最好在干净的测试系统上测试您的新安装程序。开发人员系统充满垃圾，通常不适合 MSI 测试。