自我修复，简单简短的说明：Why does the MSI installer reconfigure if I delete a file?
WiX / MSI 文件的具体设计建议
我一直在尝试写关于为开发人员重复 MSI 自我修复，但最终写得太详细了。这是我的最后一次尝试：concrete design advice for what not to do in your WiX / MSI file。
下面的答案提供了一个用于解决任何自我修复方案的清单 - 来自任何供应商或来源，而不仅仅是您自己的。检查上面链接的答案，了解您自己的 MSI 封装设计问题。
“短版” - 自我修复清单
为了永久可靠地为每个人解决自我修复问题，开发人员和设置开发人员必须参与，因为真正的修复必须在供应商级别进行。
如果您处于企业环境，质量差的应用重新打包也会导致自我修复问题，您应该让您的应用打包人员来确定是否问题出在供应商与否。
系统管理员必须知道他们在看什么，并且当没有可用的修复程序时，使用各种变通方法来解决问题。甚至最终用户也可以自己尝试一些简单的解决方法（参见第 5 节）。
自修复问题的本质：
- 大多数自我修复问题与 COM 相关，供应商和开发人员有两个常规修复：1）正确使用已部署的共享 COM 库通常通过合并模块部署，或者 2) 使用无注册 COM 来“保护”您的应用程序免受自我修复和兼容性问题的影响。
- 您的设置开发人员可以实现合并模块修复，开发人员必须进行测试。合并模块是用于共享文件的标准化共享部署库。
- 根据我的经验，无注册 COM 仅在开发人员参与的情况下才有效。如果开发人员需要使用 COM 文件的特定版本（无论出于何种原因），此选项尤其重要。详情见下文第 5.4 节。
- 除了 COM，您还可以通过让您的 安装开发人员 注册 file- 和 MIME-associations 和 MSI 设置中的strong>命令动词。谨慎使用，并确保您的文件/MIME 关联是唯一的。
- 最后，您可以通过两个已安装的 MSI 文件之间的任何文件或注册表冲突来进行自我修复。他们“错误地共享资源”并将其视为自己的资源 - 与之抗争直到冲突解决。
- 一些自我修复问题根本不是由供应商应用程序或设置中的错误引起的，而是由相关计算机环境中的外部因素引起的，例如来自修补用户、脚本、病毒、防病毒或安全软件的干扰.有关详细信息，请参阅第 3 节。
处理问题应用程序的快速选项
如果您确定您看到的自我修复仅由 MSI 引起（而不是由其他外部原因，如下文前几节所述）。
第 5 节中提出的大多数“解决方案”实际上大多是系统管理员技巧，不能解决根本问题 - 如上所述，真正的解决方案必须来自供应商。例外是“5.4：无注册 COM”，它实际上可以帮助开发人员“保护”他们的应用程序免受自我修复问题。
如果您您的盒子没有管理员权限，建议您尝试“解决方案”5.2、5.3 或 5.1（5.1一般需要管理员权限才能尝试，但并不复杂）。这些是“快速解决方法”，其他涉及更多。如果这些解决方法不起作用，请让您的管理员阅读其他建议。
了解 Windows Installer 自我修复
我之前已经详细写过这个问题，但它过于关注理解问题，而不是真正找到可接受的解决方案。您可以在此处阅读有关自修复问题的完整说明：How can I determine what causes repeated Windows Installer self-repair?。
修复 Windows Installer 自我修复问题
要真正修复重复和无休止的自我修复，您可以尝试以下第 5 节中的建议 - 按复杂性和难度递增的顺序排列。在这样做之前，您应该验证自我修复问题的真正根源是什么。它可能不是由 MSI 文件引起的，而是由其他外部原因引起的（例如脚本或用户删除文件或防病毒阻止文件）。
如果问题确实与 MSI 有关，您可以尝试禁用广告快捷方式和COM插件，使用免注册COM， 从应用程序供应商处获得帮助、卸载有问题的应用程序、虚拟化软件包或完全破解缓存的 MSI 数据库和注册表（不推荐，只有在专家帮助下才可能）。这完全取决于您的情况。如果脚本等外部原因出现故障，则必须消除这种干扰。请参阅下面的详细信息 - 只需按照清单进行操作即可。
解决问题的第一步是确定问题确实存在于您的平台上，然后首先确定哪些应用程序触发了自我修复：
1。 验证您的环境中确实存在问题。
- 通常总是有可能找出原因导致有问题的自我修复，并且有几种可行的解决方法可以用来解决问题。然而，并不总是能够找到一个好的、永久的修复（没有供应商的帮助 - 如下所述）。
- 因此，如果您是一名系统管理员，试图为您的自我修复问题寻找解决方案，也许要确保该问题出现在多台计算机上 - 特别是如果该问题出现在 开发人员身上-、QA- 甚至是测试计算机。
- 如果您只在一台计算机上看到自我修复问题，则替代方法可能是重建有问题的计算机。有效地消除而不是“解决”问题。不过，您可能会再次看到问题，但存在相对较高的风险。如果你问我，不要重建，这不是解决方案 - 但我猜在现实世界中往往会这样做。
- 请注意，安装缓慢且不断被用户中止的广告宣传的 MSI 安装可能“看起来像”桌面支持的自我修复问题，但这是预期的 MSI 行为。允许安装完成一次（可以更改安装程序进度条以禁用取消按钮 - 类似于
msiexec.exe /I "MyApp.msi" /QB-! 仅用于进度条，没有取消按钮，最后没有模式对话框）。
2。 找出肇事者进行自我修复。
-
单个应用程序可能会自行导致问题，但通常至少有 两个应用程序发生冲突（它们错误地共享某些资源） .
-
自修复触发器通常可以在发生自修复的系统上的事件查看器中找到。按照以下步骤打开事件查看器：
- 右键单击“我的电脑”
- 点击管理
- 如果收到 UAC 提示，请单击继续
- 转到事件查看器部分，然后检查 Windows 日志
- 通过查看事件日志的“应用程序部分”，在 Windows 事件日志中识别有问题的应用程序，您应该会发现来自事件源的警告“MsiInstaller”，ID 为 1001 和 1004。
3。 确认外部非 MSI 原因不会导致问题
- 手动或自动删除文件或注册表设置的任何操作都可能触发 MSI 自我修复。 尤其是当您在用户配置文件或注册表的 HKCU 部分中删除内容时弄乱了。
- 在大多数情况下，此类触发器只会导致单次自我修复运行并然后问题得到修复（这是自我修复的工作方式，并且帮助用户）。允许自我修复运行一次，然后再次启动应用程序以测试问题是否消失。应该是这样，并且您的应用程序应该从现在开始正确启动。
-
特殊情况：具有讽刺意味的是，您有时可以通过重命名其 HKCU 应用程序密钥（在注册表的用户部分）来修复损坏的应用程序，以实际强制自我修复运行并在用户中安装应用程序的默认数据profile - 如果该数据被意外删除（这种类型的修复通常不适用于终端服务器）。
- 如果相同的文件或注册表项被自动方式再次删除并且自我修复结果，您必须消除或更新导致它的自动过程并且您的问题得到解决并且您可以停止阅读。如果您自己再次手动删除该文件，那么您可能会记性不好:-)。
- 总而言之，清理脚本、登录脚本、清理应用程序或修补、过度活跃的用户都可能导致此问题一种自我修复。
- 最后，病毒和杀毒软件（和其他安全软件）可以阻止对文件的访问并触发永远不会成功的自我修复强>。
- 对于受感染的计算机，只需重建计算机即可。总体而言，这将节省您的时间。
- 对于防病毒/安全软件问题，请带您的安全人员来解决它。在某些情况下（尤其是误报），他们可能需要联系供应商。
- 无论是病毒还是反病毒相关，请检查http://www.virustotal.com 上的违规文件，以验证它实际上是病毒还是只是误报（这可能是自我修复的更大问题）。
- 我个人见过几个杀毒/安全软件相关的自我修复问题，但没有真正的病毒相关问题（目前为止）。我猜病毒通常会感染核心系统文件而不是应用程序文件，并且核心系统文件不会被MSI文件部署（共享系统文件可能包含在MSI文件中，但不包含核心系统文件）。
4。 联系供应商（或您自己的包装部门）。
5。 选择“解决方法”或修复来处理冲突情况。
6。 总结和结论
-
第 4 步 - 联系供应商进行修复 - 在我看来，这是唯一的“真正的修复”。
- 所有其他提案都试图解决供应商错误导致的问题，而不是提供持久的解决方案。
- 现实世界的问题是，许多供应商倾向于互相指责，因此您可能不走运。一些做得对的供应商确实会遭受其他人的设计错误。
-
5.1、5.2、5.3 建议不复杂“解决方法 ”。
- 应该对所有人都安全。
- 建议 5.2 和 5.3 应该可以尝试，即使 没有管理员权限。
- 提案 5.4 - 无注册 COM - 是一个相当复杂的潜在“修复”。
- 可能需要开发人员参与才能找到要“隔离”的所有相关文件。
- 根据我的经验，这种项目最终需要数天才能尝试（即使在专家帮助下） - 并不能真正保证它最终会奏效。
- 我从专家那里听到相互矛盾的事情，有些人成功了，有些人说它失败了。有权访问解决方案源的人似乎成功了。
- 我个人不喜欢它，因为它会带来潜在的安全漏洞，而且要部署的任何新文件版本都可能意味着新一轮的清单重新创作（我相信）。
- 但是，现在有问题的 COM 文件太旧了，他们不太可能看到对它们进行的任何安全更新。我想这些 COM 对象现在主要用于 .NET 互操作。
- 建议 5.5 - 虚拟化 - 是现在的常见选项，如果在环境中可用，可能应该在 5.4 之前尝试。俗话说“virtualize, seriously”。
- 老实说，我不知道（缺乏经验）虚拟化是否适用于（办公室）插件。如果可以确认，请更新。
- 可执行文件绝对可以虚拟化。
- 提案 5.6 - “缓存的 MSI 调整” - 是一个“hack”，如果由 部署专家。
- 存在一些“副作用”，尤其是对于卸载 - 以及“弹性”，但如果操作正确，这些应该是可控的。
- 这是“真实世界”——没有什么是“干净的”。
-
提案 5.7 - “zapping MSI” - 是不安全的、已弃用的“遗留黑客”。
由于系统的“脏状态”，有几个副作用。在运行 MsiZap.exe 后报告 MSI 数据库完全损坏。