我在WiX中有一个很大的程序，它使用一堆MSI，C＃自定义动作程序，UI，引导程序，你可以命名它，它就在那里。
我遇到了这个问题：当我进行重大升级时，之前的版本没有被删除。也就是说，如果我从版本1.0.0.x升级到1.1.0.x，程序＆amp;功能显示两个版本都安装在计算机上。
这是一个常见问题，SO上有许多解决方案。他们都没有为我工作 - 如果有关于此的SO帖子，我已经尝试过了。
我被告知主要升级中的组件之间存在一对一的关系。也就是说，对于每个被删除的组件，都必须添加另一个组件。如果不是一对一的关系，那么旧版本不会被删除 - 因为仍有旧组件挂起。
有没有办法确定哪些组件悬挂？比如，在日志文件中还是什么？如果我能确定MSI遇到什么问题，我可以更积极主动地解决问题。
编辑：
虽然我还没有解决问题，但多亏了Urman先生的建议，我可能会走上正轨。
我创建了该注册表项，但是......它似乎没有做任何事情。但是，我确实在我的卸载日志中搜索了单词＆＃34; Disallow＆＃34;，我发现了这个短语9次：
Disallowing uninstallation of component: {GUID-HERE} since another client exists.
此外，这个短语出现在＆＃34; Disallow＆＃34;的每个分组之前。短语：
PROPERTY CHANGE: Adding INSTALLLEVEL property. It's value is '1'.
这让我有所作为。但是，我似乎无法找到提到的GUID！他们不在我的解决方案中，也无法在注册表中搜索。除了搜索注册表，有没有办法（Windows 7 32位）找出特定GUID对应的组件？
答案 0 :(得分：1)
我被告知主要升级中的组件之间存在一对一的关系。也就是说，对于每个被删除的组件，都必须添加另一个组件。如果不是一对一的关系，那么旧版本不会被删除 - 因为仍有旧组件挂起。
这并非严格属实。它非常适用于次要升级，并且在某些配置（那些涉及晚期RemoveExistingProducts）的主要升级中也同样挑剔。但是，典型的主要升级功能更像用户选择卸载旧版本，然后安装新版本。首先验证您的假设：确保您有正确的主要升级（您更改了ProductVersion和产品代码，并在升级表中有正确的条目，对吧？）。然后诊断。
如何最好地确定发生了什么？根据我的经验，日志文件是您最好的选择。由于间接卸载旧版本，因此无法使用命令行进行记录。因此，请通过创建或设置以下注册表值来设置Logging policy。 （如果要还原设置，请在以后删除。）
HKEY_LOCAL_MACHINE \ SOFTWARE \政策\微软\的Windows \ Installer程序
值（Reg_SZ）：记录
数据：voicewarmup
然后运行主要升级，找到在％temp％中生成的相应日志文件。 （考虑提前清除％temp％以便更容易找到它。或者按日期排序。）特别注意卸载（可以通过ProductVersion识别，或者存在UPGRADINGPRODUCTCODE）。我特别注意禁止卸载包含组件GUID的组件... 等行。
一旦拥有了GUID，就必须弄清楚它是什么组件，以及它是如何进入当前状态的。您可以手动检查内置的.msi文件（使用Orca等工具）来查找组件，但很少有工具可以告诉您所有客户端。我的雇主的产品附带了一个名为InstallShield Msi Sleuth的帮助工具，可以列出引用组件代码的所有已安装产品，或者您可以从MsiEnumProducts或Installer.ComponentClients构建自己的产品。您不能直接搜索注册表，因为Windows Installer以压缩或打包的形式存储GUID。
然后确定＆＃34;为什么＆＃34;可能是困难的部分。或者它可能就像不正确的共享DLL引用计数一样简单，特别是如果您只是在已发布产品未发布版本的测试计算机上遇到此问题。
作为相关替代方案，但仅与次要升级或小型更新相关，您可以设置EnforceUpgradeComponentRules Policy。这有助于在遇到问题时发现问题，而不是让Windows Installer尽力继续。