如何使用WiX / MSI软件包避免触发MSI自我修复？

问题描述 投票：3回答：1

如何避免从我的WiX生成的MSI包中触发自我修复？

这是一个Q / A风格的问题，答案只列出了MSI文件中不要做的一些事情，以避免重复自我修复的最常见原因。

wix windows-installer installshield advanced-installer
1个回答
3
投票

自我修复，简单和简短说明：Why does the MSI installer reconfigure if I delete a file?

一般的WiX / MSI建议：这个自我修复的部分与一般MSI问题的原始答案分开：How do I avoid common design flaws in my WiX / MSI deployment solution?

简短的摘要

我一直在尝试写关于为开发人员重复MSI自我修复，但最终得到了太多的细节。这是我的最后一次尝试：针对您的WiX / MSI文件中没有做的具体设计建议。其他部署专家，请扩展下面的“陷阱列表”。

我写的早期答案原来是开发人员相关的，但不是开发人员友好的：

我认为还有时间对自我修复有另一种看法。现在我终于可以写出我一直想要的东西：开发人员自我修复的观点 - 为开发人员进行自己的设置开发工作而避免的一些缺陷 - 经常使用WiX框架。只是一个简短，具体的MSI包中无法做的事情列表。

MSI / WiX设计陷阱导致自我修复问题

这是一个粗略的初稿。如果时间允许，这些要点将会充实。

  1. 你弄乱了共享运行时的安装。您不使用合并模块来部署全局注册的和/或共享的运行时文件。而是安装自己的文件副本并在系统范围内注册它们。这对COM文件尤其不利，但也适用于其他类型的文件。冲突的应用程序将尝试恢复其状态，并在每次备用应用程序启动时“自我修复战斗”结果。
  2. 你遇到空文件夹自修复的特点。使用目录键路径创建空组件，而不添加CreateFolder条目。这导致无限循环，其中MSI删除文件夹，然后触发自我修复以将其放回。此时WiX可能会对此进行保护。
  3. 组件引用计数不正确。您自己创建一套软件包，使用不同的组件GUID从不同的MSI设置将相同名称的文件安装到磁盘上的相同位置。这很可能会触发自我修复，因为软件包“争相”将其文件版本放在适当的位置。这有几个“修复”，例如设计合并模块，使用WiX包含文件，安装文件而不引用计数（空白组件guid） - （更多细节将很快添加）。
  4. 错误的每用户文件安装。您将文件安装到用户配置文件并在HKCU中设置文件密钥路径而不是注册表密钥路径（MSI设计准则要求）。这经常导致普通用户体验重复的自我修复，因为缺少磁盘权限而永远不会成功。常规用户不会“看到”密钥文件，因为密钥文件所在的读取权限（另一个用户的用户配置文件）没有。这是一个color illustration。
  5. 错误的磁盘/注册表自定义权限。这个问题不同，但与之前的问题类似。您在安装期间应用自定义文件，文件夹和注册表权限，以删除常规用户对安装位置的读取权限。普通用户会看到重复的自我修复永远不会成功。这也可能发生在“每台机器”文件位置，而不仅仅是用户配置文件路径（如上一期）。我听说有些人已经看到了这一点，特别是对于写保护的ini文件。
  6. 您为临时文件启用了ref-counting。出于某些疯狂的原因，您决定将文件安装到tmp文件夹或其他可能随时清理的文件夹中。也许您打算从自定义操作或其他操作中运行该文件。在任何一种情况下，您都可以通过具有组件guid和密钥路径集的组件进行安装，当文件从磁盘“清除”时，您的MSI文件将尝试将其恢复。每次“清理”文件时都会重复此操作。由于安装位置可能是每个用户的位置，因此其他用户可能无法从其登录中“看到”该文件，并且他们会立即体验重复的自我修复，而您只能在文件被“清理”时看到它。
  7. 恶意软件 - 真实和误报。您安装了一个不常见的二进制文件，而不通过基本的病毒/恶意软件筛选运行检查实际的恶意软件和检查误报一样重要（一个恶意软件扫描服务使用的是http://www.virustotal.com - 几乎70种不同的扫描仪 - 显然需要特别关注主要供应商）。因此，您忽略了恶意软件检查，并且在部署之后，您的产品遭受来自多个反病毒软件供应商的误报，并且自我修复将徒劳无功地尝试将文件放回以使其再次“隔离”。你的客户责备你。如果您实际安装了真正的病毒或恶意软件，结果当然同样糟糕。结果完全相同 - 自我修复一直无法运行。另一方面，如果二进制文件在安装后被感染，那么自我修复应该用于其目的并运行一次以将干净文件放回原位。主要问题是修复误报实际上比处理恶意软件更难（如果恶意软件导致数据丢失，恶意软件对客户来说当然更糟，但据了解，这是软件提供商无法做到的）。使用恶意软件，您只需告诉您的客户重建他们的PC并重新安装您的软件，但是如果误报，您需要做一些事情将二进制文件列入白名单 - 通常是与几家安全软件供应商合作。你是如何处理这个过程的？由于恶意软件似乎变得越来越糟，并且尝试以任何可能的方式收紧安全性，误报可能会成为一个主要的部署问题 - 甚至比现在更加严重。试图将二进制文件列入白名单可能会浪费很多时间。显而易见，但我们只是大声说出来：不要自己作为部署人员勇敢地完成这项任务 - 这个白名单是一项需要管理层参与的巨大任务。这个问题会影响软件供应商的一切：销售，开发，营销和支持。随着安全软件变得更加先进和“智能” - 他们可能会开始在%SystemRoot%\Installer（用于维护安装，修复和卸载）的系统上隔离整个缓存的MSI。发生这种情况时，不可能进行自我修复 - 也不会卸载（！） - 除非您可以访问用于安装的确切原始MSI。在这些情况下，我想你可以尝试一下这里列出的一些选项，让你的MSI卸载恶意软件或误报：Why does MSI require the original .msi file to proceed with an uninstall?或第12节：Uninstalling an MSI file from the command line without using msiexec。
  8. 您安装可能被用户删除的桌面文件。这是一个“边缘情况”，要求您还错误地将安装组件的密钥路径设置为磁盘密钥路径（而不是正确的HKCU路径）。大多数时候你在桌面上放置快捷方式，这很好。但是，如果您安装某个用户然后删除的某种数据文件，您可以通过自定义的快捷方式启动应用程序，或者即使实例化广告的COM对象或特定的文件类型，也可以通过自我修复看到它推出。
  9. 您将广告的快捷方式安装到“Startup”文件夹。不要将广告的快捷方式安装到“Startup”文件夹中。它可以触发自我修复以在每次系统启动时运行，而根本不进行任何用户交互。据报道，删除快捷方式也会触发自我修复。这是我从未见过的东西，但它是有道理的。
  10. 您使用应用程序更改的HKCU密钥路径（或HKLM）。您从MSI写入注册表的任何设置通常都不应被修改，或者更糟糕的是，应用程序的操作将删除。可能会导致自我修复。仅写入应用程序刚刚读取的数据。您的应用程序本身应始终将所有默认设置填充到HKCU，您的设置不应该干扰它们。 userprofile文件也是如此。应从每个计算机模板位置为每个用户复制它们。故事的整体道德：仅部署每台机器文件和设置（HKLM）。其他所有内容都应该由应用程序初始化：Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?。
  11. 您的设置会写入由组策略定期覆盖的注册表项。我相信我第一次看到这个问题与使用MSI设置的HKCU中的一些IE代理设置密钥有关。由于很多原因，使用MSI设置几个注册表项总是一个坏主意。请参阅此serverfault.com答案以获取几个问题的列表：MSI package for reg deployment（建议快速阅读，尽管它与系统管理员最相关，但对于开发人员来说很重要）。我在重现此问题时遇到问题，因为当关键路径丢失时（通常不仅仅是更改或修改）会触发自我修复。也许团体政策实际上删除了MSI增加的HKCU值？我们确实看到了这个问题，所以这可能就是发生了什么。总体消息：永远不要使用MSI来设置几个注册表项，特别是如果它们在HKCU中。使用组策略，登录脚本，VB脚本，PowerShell或其他更可靠的措施，例如让应用程序在启动时执行（每个用户一次）。
  12. 您在MSI文件中注册特定的文件/ MIME关联或命令谓词。大多数自我修复似乎是由COM注册表之间的干扰触发的，这些产品触发了COM对象实例化时的自修复，或者调用了广告的快捷方式。但是，您也可以通过文件/ MIME关联和命令谓词触发自我修复。特别是文件关联可以由系统上的其他应用程序/ MSI文件注册，这可能会触发非常持久的自我修复，因为每个应用程序都试图“窃取”文件关联。在MSI中谨慎使用这些功能 - 并确保您注册的文件关联确实是唯一的。永远不要在MSI设置中设置“通用”文件关联（例如jpg）。
  13. 错误地安装了两次（或更多）相同的MSI。这听起来很奇怪，但实际上有几种可能。如果发生这种情况，自我修复可能不是您最大的问题，您也会看到其他问题： 您忘记为重建的MSI生成新的包GUID。然后，Windows Installer将两个不同的MSI文件视为“按定义”相同的文件。我相信在这些情况下我已经看到了自我修复，但你也将面临许多其他问题，同样奇怪。始终自动生成包GUID。没有理由让任何两个MSI文件具有相同的包GUID（除非您在Windows Installer引擎中测试一些令人难以置信的模糊内容）。虽然完全意识到重复GUID的问题，但在很多年前，在一些非常繁忙的开发中使用Installshield仍然发生在我身上。我仍然想知道它到底是怎么发生的 - 但事实确实如此。也许这是工具中未知的错误？ 主要升级失败可能会同时安装两个版本的安装程序。您在添加/删除程序中看到两个条目。在这些情况下，自修复问题是可能的，但是其他问题也很多。根据我的经验，这个问题很严重，但没有像为两个MSI文件使用相同的包GUID那样糟糕（前一个项目符号点）。 我相信还有其他几种方法可以将同一产品最终安装多次。也许失败的multi-instance transforms也可能导致问题？我不喜欢这个特定的概念所以我没有真正尝试过。

一些一般的“亚军”自我修复相关问题：

  • 在您的MSI上运行验证，将标记并轻松消除上述几个问题。
  • 切勿在开发人员工具箱或任何无法轻易恢复的计算机上运行MsiZap.exe。实际上根本不要使用这个“工具”。在MsiZap.exe对MSI数据库进行核心创建的“脏状态”之上进行部署时，您经常会看到自修复问题。
  • 如果你需要安装COM shell扩展，请确保在使用Windows资源管理器时进行彻底测试，并在不同的视图模式之间切换以检查是否自我修复。像这样的COM对象基本上是连续使用的，因此自我修复很可能（确定）是否有任何设置受到干扰。
  • 如果您在功能中单独放置一个广告快捷方式，它几乎不会触发自我修复。密钥路径检查是针对快捷方式所针对的功能及其所有父功能（上次我检查;-) - 多年前完成的。

自我修复相关答案（保管链接）：

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.