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

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

问题描述

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

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

这是一个 Q / A风格的问题，其答案仅列出了MSI文件中不需要执行的一些操作，以避免重复自我修复的最常见原因。

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.

推荐答案


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






一般WiX / MSI建议 ：此自我修复工具与一般MSI的原始答案相差
问题：
如何避免WiX / MSI部署解决方案中常见的设计缺陷？

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?





简短摘要



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

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:

  • How can I determine what causes repeated Windows Installer self-repair? - Focuses on understanding the self-repair problem in general. Setup developer / application packager focus.
  • What do I do when launching an application triggers repeating, endless Windows Installer self-repair? - Provides a checklist for solving self-repair scenarios. "How to fix focus" - rather than just understanding. For developers, sysadmins, application packagers and end users. How to handle bad MSI packages in general - from any vendor or source, not just your own.

我认为还有时间关于自我修复的另一种观点。现在，我终于可以写出我一直想要的内容：开发人员的自我修复观点-一些进行自己的设置开发工作的开发人员需要避免的陷阱使用 WiX框架。

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.

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

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


  1. 您弄乱了共享运行时的安装。您不使用合并模块来部署全局注册的和/或共享的运行时文件。而是您可以安装自己的文件副本并在系统范围内注册它们。这对于COM文件特别有害，但也适用于其他类型的文件。冲突的应用程序将尝试恢复其状态，并在每次其他应用程序启动时产生自我修复的结果。

  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.

文件夹自修复特性。您创建具有目录键路径的空组件，而无需添加CreateFolder条目。这将导致无限循环，在该循环中，MSI删除文件夹，然后触发自我修复以将其放回去。此时，WiX中可能对此有所保护。

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.

错误的组件引用计数。您自己创建一个软件包套件，并使用不同的组件GUID从不同的MSI设置中将具有相同名称的文件安装到磁盘上的相同位置。这很可能会触发自修复，因为程序包会拼搏以放置其文件版本。为此，有几个修复程序，例如设计合并模块，使用WiX包含文件，安装不包含引用计数的文件（空白组件guid）-（稍后将添加更多详细信息）。

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).

每用户文件安装错误。您将文件安装到用户配置文件中，并在HKCU中设置文件密钥路径而不是注册表密钥路径（MSI设计准则要求）。这经常导致普通用户遇到重复的自我修复，由于缺少磁盘权限，该修复从未成功。普通用户无法看到密钥文件，因为密钥文件所在的位置（另一用户的用户个人资料）没有读取权限。这是彩色插图。

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.

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

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.

您为临时文件保留了引用计数功能。由于某种疯狂的原因，您决定将文件安装到tmp文件夹或随时可以清理的另一个文件夹。也许您打算通过自定义操作或其他方式运行文件。无论哪种情况，都可以通过设置了组件guid和密钥路径的组件来安装它，并且当从磁盘清除文件时，MSI文件将尝试将其放回去。每次清除文件时都会重复一次。由于安装位置可能是每个用户的位置，因此其他用户可能无法从登录名看到该文件，因此他们会立即经历重复的自我修复，而只有在清除文件后才能看到该文件。

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".

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

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.

您将安装可能被用户删除的桌面文件。这是一种附带情况，要求您还将安装组件的密钥路径错误地设置为磁盘密钥路径（而不是正确的HKCU路径）。大多数时候，您都将快捷方式放在桌面上，这很好。但是，如果安装了用户随后删除的某种数据文件，则在通过公告的快捷方式启动应用程序时，或者即使实例化了公告的COM对象或特定的文件类型，您都可能会看到该文件通过自我修复而被退回。

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.

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

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.

您使用HKCU密钥路径（或与此相关的HKLM）应用程序更改。您从MSI写入注册表的任何设置通常都不会被应用程序的操作修改或删除。可能会导致自我修复。只写应用程序刚刚读取的数据。您的应用程序本身应始终将所有默认设置填充到HKCU中，并且您的设置应永远不会干扰它们。用户配置文件也是如此。应该从每台计算机的模板位置为每个用户复制它们。故事的总体寓意：仅部署每台计算机的文件和设置（HKLM）。其他所有内容都应由应用程序初始化：为什么在使用MSI时将文件部署限制在用户配置文件或HKCU中是一个好主意？。

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?.

您的设置写入由组策略定期覆盖的注册表项。我相信我首先看到与使用MSI设置HKCU中的某些IE代理设置键有关的问题。由于许多原因，使用MSI仅设置一些注册表项始终是一个坏主意。请参阅此serverfault.com答案以获取以下几个问题的列表： 用于注册表部署的MSI软件包 （建议快速阅读，尽管它与系统管理员最相关，但对于开发人员来说很重要）。我很难重现此问题，因为在缺少关键路径（通常不只是更改或修改）时会触发自我修复。也许组策略实际上删除了MSI添加的HKCU值？我们确实看到了问题，所以很可能就是这样。 总体消息：永远不要使用MSI来设置一些注册表项，尤其是在HKCU中。请使用组策略，登录脚本，VB脚本，PowerShell或其他，更可靠的措施，例如让应用程序在启动时执行（每个用户一次）。

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).

您注册了特定的文件/ MIME关联或命令动词在您的MSI文件中。大多数自我修复似乎是由产品之间的COM注册表干扰触发的，这些产品在COM对象实例化或触发公告的快捷方式时触发自我修复。但是，您也可以通过文件/ MIME关联和命令动词触发自我修复。特别是，文件关联可以由系统上的其他应用程序/ MSI文件注册，并且当每个应用程序试图偷回文件关联时，这可能会触发非常持久的自我修复。在您的MSI中谨慎使用这些功能-确保您注册的文件关联确实是唯一的。永远不要在您的MSI设置中设置通用文件关联（例如jpg）。

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).

同一MSI通过两次安装（或多次安装） 。这听起来很奇怪，但实际上有几种可能。如果发生这种情况，自我修复可能不是您的最大问题，那么您还将看到其他问题：

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:


  • 您忘记生成新的包GUID为您重建的MSI。然后，Windows Installer会将两个不同的MSI文件视为按定义相同的文件。我相信在这些情况下我已经看到了自我修复，但是您也将面临很多其他问题，这些问题同样令人奇怪。始终自动生成程序包GUID。没有任何两个MSI文件具有相同的程序包GUID的理由（除非您要在Windows Installer Engine中测试令人难以置信的东西）。尽管我完全意识到重复GUID的问题，但很多年前在某些繁忙的开发过程中使用Installshield仍然使我想到了。我仍然想知道它实际上是如何发生的-但是确实如此。

  • 重大升级失败会导致同时安装两个版本的安装程序。您会在添加/删除程序中看到两个条目。在这些情况下，可能会出现自我修复问题，但其他许多问题也是可能的。以我的经验，这个问题很严重，但不如对两个MSI文件使用相同的软件包GUID（先前的项目符号要点）。

  • 我确信同一产品还有其他几种方法最终可能会被安装多次。可能失败 多-实例转换 也会引起问题吗？我不喜欢这个特定的概念，所以我还没有真正尝试过。

  • 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.





一些一般的运行程序自我修复相关问题：




  • 在MSI和上面的几个问题将被标记并轻松消除。

  • 切勿在开发人员工具箱或无法轻松还原的任何计算机上运行 MsiZap.exe 。实际上根本不使用此工具。在MsiZap.exe对MSI数据库的限制下创建的脏状态上进行部署时，通常会遇到自我修复问题。

  • 如果需要安装COM shell扩展，确保在使用Windows资源管理器时进行彻底测试，并在不同的视图模式之间进行切换，以检查是否启动了自我修复。像这样的COM对象本质上是连续使用的，因此（一定）很有可能进行自我修复（如果有的话）

  • 如果您自己在功能中放置广告快捷方式，则几乎绝不会触发自我修复。快捷键所在的功能及其所有父功能（我上次检查;-－几年前）已完成了关键路径检查。

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

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