如何避免使用我的 WiX/MSI 包触发 MSI 自我修复? [英] How do I avoid triggering MSI self-repair with my WiX / MSI package?

查看：22
本文介绍了如何避免使用我的 WiX/MSI 包触发 MSI 自我修复?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

<小时>

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

解决方案

自我修复，简单 &简短说明:如果我删除文件，为什么 MSI 安装程序会重新配置?

<小时><块引用>

一般 WiX/MSI 建议:这个自我修复部件是从关于一般 MSI 问题的原始答案中分离出来:如何避免我的 WiX/MSI 部署解决方案中的常见设计缺陷?

<小时>

小结

我一直在尝试写关于为开发人员重复 MSI 自我修复，但最终写得太详细了.这是我的最后一次尝试:具体的设计建议在您的 WiX/MSI 文件中不应该做的事情.其他部署专家，请扩展下面的陷阱列表".

<小时>

我写的较早的答案结果与开发人员相关，但对开发人员不友好:

我认为还有时间从另一个角度来看待自我修复.现在我终于可以写出我一直以来的意图了:开发人员对自我修复的看法 - 对于自行进行设置开发工作的开发人员来说，要避免的一些陷阱 - 通常使用 WiX 框架.只是一个简短的、具体的清单，列出了在您的 MSI 包中不要做的事情.

<小时>

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

这是一个粗略的初稿.这些要点将在时间允许时充实.

  1. 您搞砸了共享运行时的安装.您不使用合并模块来部署全局注册的和/或共享的运行时文件.相反，您安装自己的文件副本并在系统范围内注册它们.这对 COM 文件尤其不利，但也适用于其他类型的文件.冲突的应用程序将尝试恢复其状态，并且在每次启动备用应用程序时都会产生自我修复战斗".

  2. 你遇到空文件夹自修复特性.您使用目录键路径创建一个空组件，而不添加 CreateFolder 条目.这会导致无限循环，MSI 会删除该文件夹，然后触发自我修复将其放回原处.此时，WiX 中可能会对此提供保护.

  3. 组件引用计数不正确.您自己创建一个软件包套件，使用不同的组件 GUID 从不同的 MSI 设置将同名文件安装到磁盘上的相同位置.这很可能会触发自我修复，因为包战斗"以将其文件版本放置到位.对此有几个修复"，例如设计合并模块、使用 WiX 包含文件、安装没有引用计数的文件(空白组件 guid)-(更多细节将很快添加).

  4. 每个用户的文件安装错误.您将文件安装到用户配置文件并设置文件密钥路径而不是 HKCU 中的注册表密钥路径(MSI 设计指南要求).这经常导致普通用户经历重复的自我修复，由于缺少磁盘权限而永远不会成功.普通用户看不到密钥文件，因为密钥文件所在的位置(另一个用户的用户配置文件)没有读取权限.这是一个 彩色插图.

  5. 错误的磁盘/注册表自定义权限.这个问题是不同的，但与上一个问题相似.您在安装期间应用自定义文件、文件夹和注册表权限，从而删除普通用户对安装位置的读取权限.普通用户会看到重复的自我修复，但永远不会成功.这也可能发生在每台机器"文件位置，而不仅仅是用户配置文件路径(如上一期).我听说有些人特别是在写保护的 ini 文件中也看到了这一点.

  6. 您为临时文件启用了引用计数.出于某种疯狂的原因，您决定将文件安装到 tmp 文件夹或可能随时清理的另一个文件夹.也许您打算通过自定义操作或其他方式运行文件.在任何一种情况下，您都通过具有组件 guid 和密钥路径集的组件安装它，并且当文件从磁盘清理"时，您的 MSI 文件将尝试将其放回原处.每次清理"文件时都会重复此操作.由于安装位置可能是每个用户的位置，其他用户可能不会从他们的登录中看到"该文件，并且他们会立即体验到重复的自我修复，而您只有在清理"文件时才能看到它.

  7. 恶意软件 - 真实和误报.您安装一个不寻常的二进制文件，而无需通过基本的病毒/恶意软件筛选运行它.检查实际恶意软件与检查误报同样重要(要使用的恶意软件扫描服务是 http://www.virustotal.com - 近 70 种不同的扫描仪 - 特别注意主要供应商 - 显然).因此，您忽略了恶意软件检查，并且在部署后，您的产品会遭受多家防病毒供应商的误报，并且尝试将文件放回原处的自我修复将徒劳无功，只是再次将其隔离".你的客户责备你.如果您实际安装的是真正的病毒或恶意软件，结果当然同样糟糕.结果一模一样——自修复一直在白跑.另一方面，如果二进制文件在安装后被感染，那么自我修复应该发挥其作用并运行一次以将干净的文件放回原处.主要问题是修复误报实际上比处理恶意软件更难(如果恶意软件导致数据丢失，客户当然会更糟，但可以理解的是作为软件提供商，这超出了您的掌控).对于恶意软件，您只需告诉您的客户重建他们的 PC 并重新安装您的软件，但对于误报，您需要做一些事情来将您的二进制文件列入白名单 - 通常与多家安全软件供应商合作.您如何处理这个过程? 随着恶意软件似乎变得越来越严重，并且试图以任何可能的方式加强安全性，误报很可能成为主要的部署问题 - 甚至比现在更严重.尝试将二进制文件列入白名单可能会浪费大量时间.显而易见，但让我们大声说出来:作为部署人员，不要独自勇敢地完成这项任务 - 这个白名单是一项需要管理层参与的艰巨任务.这个问题影响到软件供应商的一切:销售、开发、营销和支持.随着安全软件变得更加先进和智能"——它们可能会开始隔离系统上在 %SystemRoot%Installer 中找到的整个缓存的 MSI(用于维护安装、修复和卸载).发生这种情况时，将无法进行自我修复 - 也无法卸载 (!) - 除非您可以访问用于安装的确切原始 MSI.在这些情况下，我想您可以尝试此处列出的一些选项来卸载带有恶意软件或误报的 MSI:为什么 MSI 需要原始 .msi 文件才能继续卸载? 或此处的第 12 节:从命令行卸载 MSI 文件不使用 msiexec.

  8. 您安装的桌面文件可能会被用户删除.这是一个边缘情况"，要求您还错误地将安装组件的密钥路径设置为磁盘密钥路径(而不是正确的 HKCU 路径).大多数时候，您将快捷方式放在桌面上，这很好.但是，如果您安装了用户随后删除的某种数据文件，当您的应用程序通过广告快捷方式启动时，或者即使广告的 COM 对象被实例化或特定文件类型，您可能会看到它通过自我修复恢复已启动.

  9. 您将宣传的快捷方式安装到启动"文件夹.不要将宣传的快捷方式安装到启动"文件夹.它可以触发自我修复以在每次系统启动时运行，而无需任何用户交互.据报道，删除快捷方式也会触发自我修复.这是我从未真正见过的东西，但它是有道理的.

  10. 您使用您的应用程序更改的 HKCU 密钥路径(或 HKLM).您从 MSI 写入注册表的任何设置通常都不应被修改，或者更糟的是，不应被应用程序的操作删除.可能会导致自我修复.仅写入应用程序刚刚读取的数据.您的应用程序本身应始终将所有默认设置填充到 HKCU，并且您的设置不应干扰它们.用户配置文件也是如此.应该从每台机器的模板位置为每个用户复制它们.故事的整体寓意:仅部署每台机器的文件和设置 (HKLM).其他一切都应由应用程序初始化:为什么在使用 MSI 时限制将文件部署到用户配置文件或 HKCU 是个好主意?.

  11. 您的设置会写入注册表项，这些注册表项会定期被组策略覆盖.我相信我第一次看到这个问题与使用 MSI 设置 HKCU 中的某些 IE 代理设置键有关.由于很多原因，使用 MSI 只设置几个注册表项总是一个坏主意.请参阅此 serverfault.com 答案以获取多个问题的列表:用于 reg 部署的 MSI 包(推荐快速阅读，虽然它与系统管理员最相关，但对开发人员来说很重要).我无法重现此问题，因为在缺少关键路径时会触发自我修复(通常不仅仅是更改或修改).也许组策略实际上删除了 MSI 添加的 HKCU 值?我们确实看到了问题，所以这可能就是发生了什么.总体信息:切勿使用 MSI 来设置几个注册表项，尤其是在 HKCU 中时. 使用组策略、登录脚本、VB 脚本、PowerShell 或其他，更可靠的措施，例如让应用程序在启动时执行(每个用户一次).

  12. 您在 MSI 文件中注册了特定文件/MIME 关联或命令动词.大多数自我修复似乎是由在 COM 对象实例化上触发自我修复的产品之间的 COM 注册表干扰触发的，或者是广告快捷方式的调用.但是，您也可以通过文件/MIME 关联和命令动词触发自我修复.特别是文件关联可以由系统上的其他应用程序/MSI文件注册，这可能会触发非常持久的自我修复，因为每个应用程序都试图窃取"文件关联.在您的 MSI 中谨慎使用这些功能 - 并确保您注册的文件关联确实是独一无二的.切勿在 MSI 设置中设置通用"文件关联(例如 jpg).

  13. 错误地安装了两次(或多次)相同的 MSI. 这听起来很奇怪，但实际上有多种可能.如果发生这种情况，自我修复可能不是您最大的问题，您还会看到其他问题:

    • 您忘记为重建的 MSI 生成新的包 GUID.然后，Windows 安装程序将两个不同的 MSI 文件视为按定义"相同的文件.我相信我已经在这些情况下看到了自我修复，但是您也会面临许多其他问题，所有这些问题都同样奇怪.始终自动生成包 GUID.没有理由让任何两个 MSI 文件具有相同的包 GUID(除非您在 Windows 安装程序引擎中测试一些非常模糊的东西).虽然完全意识到重复 GUID 的问题，但多年前我在一些非常繁忙的开发过程中使用 Installshield 时仍然发生这种情况.我仍然想知道它实际上是如何发生的——但它确实发生了.也许这是工具中的未知错误?
    • 主要升级失败可能会同时安装两个版本的设置.您会在添加/删除程序中看到两个条目.在这些情况下，可能会出现自我修复问题，但还有许多其他问题.以我的经验，这个问题很严重，但还不如对两个 MSI 文件使用相同的包 GUID(上一个要点).
    • 我敢肯定，同一产品最终会通过多种其他方式安装多次.也许失败了 multi-实例转换 也会导致问题吗?我不喜欢那个特定的概念，所以我没有真正尝试过.

<小时>

一些一般的亚军"自修复相关问题:

  • 在您的 MSI 上运行验证，上述几个问题将被标记并轻松消除.
  • 切勿在您的开发者机器或任何您无法轻易恢复的机器上运行 MsiZap.exe.事实上，根本不要使用这个工具".当部署在 MsiZap.exe 对 MSI 数据库的 nuking 创建的脏状态"之上时，您经常会看到自我修复问题.
  • 如果您需要安装 COM shell 扩展，请务必在使用 Windows 资源管理器时进行彻底测试，并在不同的视图模式之间切换以检查是否可以进行自我修复.像这样的 COM 对象本质上是在持续使用，并且可以自我修复.因此，如果任何设置受到干扰，则很有可能(确定)进行修复.
  • 如果您将宣传的快捷方式单独放入功能中，它几乎不会触发自我修复.对快捷方式所在的功能及其所有父功能进行了关键路径检查(我上次检查 ;-) - 这是几年前的事了).
<小时>

自修相关解答(保管链接):

How do I avoid triggering self-repair from my WiX generated MSI package?

This is a Q/A-style question with an answer that just list a few things not to do in your MSI file to avoid the most common causes of repeating self-repair.

解决方案

Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?

General WiX / MSI Advice: This self-repair piece was split from the original answer on general MSI problems: How do I avoid common design flaws in my WiX / MSI deployment solution?

Short Summary

I keep trying to write about repeating MSI self-repair for developers, but end up with too much detail. Here is my last attempt: concrete design advice for what not to do in your WiX / MSI file. Other deployment specialists, please extend the "pitfall list" below.

The earlier answers I wrote turned out to be developer relevant, but not developer friendly:

I think there is time for yet another perspective on self-repair. Now I can finally write what I intended all along: the developer's view of self-repair - some of the pitfalls to avoid for developers who do their own setup development work - often using the WiX framework. Just a short, concrete list of things not to do in your MSI package.

MSI / WiX design pitfalls causing self-repair issues

This is a rough first-draft. These bullet points will be fleshed out when time allows.

  1. You mess up the installation of shared runtimes. You don't use merge modules to deploy globally registered, and/or shared runtime files. Rather you install your own copies of the files and register them system-wide. This is particularly bad for COM files, but applies also to other types of files. Conflicting applications will try to put their state back, and "self-repair fighting" results on every alternate application launch.

  2. You run into the empty folder self-repair peculiarity. You create an empty component with a directory key path without adding a CreateFolder entry. This causes an endless loop where MSI removes the folder and then triggers self-repair to put it back. There might be protection in WiX against this at this point.

  3. Incorrect component reference counting. You create a suite of packages yourself that install a file with the same name to the same location on disk from different MSI setups using different component GUIDs. This will most likely trigger self-repair as the packages "fight" to put its version of the file in place. There are several "fixes" for this such as designing a merge module, using a WiX include file, installing the file without reference counting (blank component guid) - (more details will be added soon).

  4. Erroneous per-user file installation. You install files to the user-profile and set a file key path instead of a registry key path in HKCU (required by MSI design guidelines). This frequently cause regular users to experience repeating self-repair that never succeeds due to missing disk permissions. The key files are not "seen" by the regular user because there is no read permission where the key file resides (another user's user-profile). Here is a color illustration.

  5. Erroneous disk / registry custom permissioning. This problem is different, but similar to the previous issue. You apply custom file, folder and registry permissions during installation that removes read access to installation locations for regular users. Regular users will see repeating self-repair that never succeeds. This can happen to "per machine" file locations as well, not just user-profile paths (like the previous issue). I hear rumors that some have seen this in particular for write protected ini files as well.

  6. You leave ref-counting enabled for temp files. For some crazy reason you decide to install a file to the tmp folder or another folder that might be cleaned up at any point. Perhaps you intend to run the file from a custom action or something. In either case you install it via a component with a component guid and a key path set, and when the file is "cleaned" from disk, your MSI file will try to put it back. This repeats every time the file is "cleaned". Since the install location is likely a per-user location, other users might not "see" the file from their login, and they experience immediate, repeating self-repair whereas you only see it when the file is "cleaned".

  7. Malware - real and false positives. You install an unusual binary without running it through a basic virus / malware screening. It is as important to check for actual malware as it is to check for false positives (one malware scanning service to use is http://www.virustotal.com - almost 70 different scanners - pay special attention to the major vendors - obviously). So you ignore the malware check, and after deployment your product suffers false positives from several anti-virus vendors and self-repair will run in vain trying to put back the file only to have it "quarantined" again. Your customers blame you. The result is of course equally bad if you actually install a real virus or malware instead. The result is exactly the same - self-repair keeps running in vain. On the other hand, if the binary was infected after installation, then self-repair should serve its purpose and run once to put the clean file back in place. The major problem is that fixing a false positive is actually harder than dealing with malware (malware is of course worse for the customer if it causes data loss, but it is understood that this is out of your hands as software provider). With malware you simply tell your client to rebuild their PCs and reinstall your software, but with a false-positive you need to do something to whitelist your binary - often with several security software vendors. How do you deal with this process? As malware seems to become worse and worse and security is attempted tightened in any way possible, false positives are likely to become a major deployment problem - even more so than now. A lot of time can be wasted trying to get your binary whitelisted. And the obvious, but let's just say it out loud: don't brave this task on your own as a deployment person - this whitelisting is a huge task that requires management involvement. The problem affects everything for a software vendor: sales, development, marketing and support. As security software become more advanced and "smart" - they may start to quarantine the whole cached MSI on the system that is found in %SystemRoot%Installer (used for maintenance installs, repair and uninstall). When this happens no self-repair will be possible - and also no uninstall (!) - unless you have access to the exact, original MSI that was used to install with. In these cases I suppose you could try some of the options listed here to get your MSI with malware or false-positives uninstalled: Why does MSI require the original .msi file to proceed with an uninstall? or section 12 here: Uninstalling an MSI file from the command line without using msiexec.

  8. You install desktop files likely to be deleted by the user. This is a "fringe case" requiring that you have also erroneously set the key path for the installing component to a disk key path (rather than the correct HKCU path). Most of the time you put shortcuts on the desktop, and this is fine. However, if you install a data file of some sort that the user then deletes, you could see it put back by self repair when your application is launched via an advertised shortcut, or even if a advertised COM object is instantiated or a particular file type is launched.

  9. You install advertised shortcuts to the "Startup" folder. Don't install advertised shortcuts to the "Startup" folder. It can trigger self-repair to run on every system startup without any user interaction taking place at all. Deleting the shortcut has been reported to also trigger self-repair. This is something I have never actually seen, but it makes sense.

  10. You use a HKCU key path (or HKLM for that matter) that your application changes. Any setting you write from your MSI to the registry should generally not be modified, or worse, deleted by your application's operation. Self-repair will likely result. Only write data that the application just reads. Your application itself should always populate all default settings to HKCU, and your setup should never interfere with them. The same goes for userprofile files. They should be copied for each user from a per-machine template location. The overall moral of the story: deploy only per-machine files and settings (HKLM). Everything else should be initialized by the application: Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?.

  11. Your setup writes to registry keys that are periodically overwritten by group policy. I believe I first saw this problem in relation to some IE proxy settings keys in HKCU being set using an MSI. Using an MSI to just set a few registry keys is always a bad idea for a lot of reasons. Please see this serverfault.com answer for a list of several problems: MSI package for reg deployment (recommended quick read, though it is most relevant for system administrators, but important to know about for developers). I am having trouble reproducing this problem since self-repair is triggered when key paths are missing (generally not just changed or modified). Perhaps group policy actually removed the HKCU values that were added by the MSI? We did see the problem, so this is probably what happened. The overall message: never use an MSI to just set a few registry keys, particularly if they are in HKCU. Use group policy, logon scripts, VB Scripts, PowerShell or other, more reliable measures such as having applications do it on launch (once per user).

  12. You register a particular file / MIME association or command verb in your MSI file. Most self-repair seems to be triggered by COM registry interference between products that triggers self-repair on COM object instantiation, or the invocation of an advertised shortcut. However, you can also trigger self-repair via file / MIME associations and command verbs. In particular file associations could be registered by other applications / MSI files on the system, and this could trigger very persistent self-repair as each application tries to "steal back" the file association. Use these features sparingly in your MSI - and make sure the file associations you register really are unique. Never set a "common" file association in your MSI setup (for example jpg).

  13. The same MSI is installed twice (or more) by mistake. This sounds strange, but it is possible in several ways actually. Self-repair might not be your biggest problem if this happens, you will see other problems too:

    • You forget to generate a new package GUID for your rebuilt MSI. Windows Installer then treats the two different MSI files as the same file "by definition". I believe I have seen self-repair in these cases, but you will be facing a plethora of other problems as well, all equally weird. Always auto-generate the package GUID. There is no reason for any two MSI files to have the same package GUID (unless you are testing something incredibly obscure in the Windows Installer Engine). While fully aware of the problem of duplicate GUIDs, it still happened to me many years ago using Installshield during some very hectic development. I still wonder how it actually happened - but it did. Perhaps it was an unknown bug in the tool?
    • A failed major upgrade can leave two versions of your setup installed at the same time. You see two entries in add/remove programs. Self-repair problems are possible in these cases, but so are a plethora of other problems. In my experience this problem is serious, but not as bad as using the same package GUID for two MSI files (previous bullet point).
    • I am sure there are several other ways the same product can end up being installed multiple times. Perhaps failed multi-instance transforms can cause the problem as well? I dislike that particular concept so I haven't really tried.

Some general "runner-up" self-repair related issues:

  • Run validation on your MSI and several of the above issues will be flagged and easily eliminated.
  • Never run MsiZap.exe on your developer box or any machine that you can't easily revert. In fact don't use this "tool" at all. You will often see self-repair problems when deploying on top of the "dirty state" created by the MsiZap.exe's nuking of the MSI database.
  • If you need to install COM shell extensions, make sure to test thoroughly when using Windows Explorer and switch between different view modes to check if self-repair kicks in. A COM object like this is essentially in continuous use, and self-repair is hence very likely (certain) if any settings are interfered with.
  • If you put an advertised shortcut in a feature by itself it should almost never trigger a self-repair. Key path checking is done for the feature the shortcut is in and for all its parent features (last time I checked ;-) - which was years ago).

Self-repair related answers (links for safekeeping):

这篇关于如何避免使用我的 WiX/MSI 包触发 MSI 自我修复?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆