Ste*_*mul
6
自我修复,简单和简短说明:如果删除文件,为什么MSI安装程序会重新配置？
WiX/MSI文件的具体设计建议
我一直在尝试写关于为开发人员重复MSI自我修复,但最终得到了太多的细节.这是我的最后一次尝试:针对您的WiX/MSI文件中没有做的具体设计建议.
下面的答案提供了一个清单,用于解决任何供应商或来源,而不仅仅是您自己的自修复方案.检查上面链接的答案,了解您自己的MSI包设计问题.
"短版" - 自我修复清单
为了永久可靠地修复每个人的自修复问题,开发人员和设置开发人员必须参与其中,因为真正的修复必须在供应商级别进行.
如果您处于企业环境中,劣质应用程序重新打包也会导致自我修复问题,您应该让应用程序打包程序确定问题是否来自供应商.
系统管理员必须知道他们正在查看什么,并且当没有可用的修复时,使用各种解决方法来解决这个问题.即使是最终用户也可以尝试一些简单的解决方法(参见第5节).
自修复问题的实质:
- 大多数自修复问题都与COM有关,对供应商和开发人员有两个常规修复:1)使用通常通过合并模块部署的正确部署的共享COM库,或2)使用无需注册的COM来"屏蔽"您的应用程序来自修复和兼容性问题.
- 您的安装开发人员可以实现合并模块修复,开发人员必须测试.合并模块是标准化的共享文件共享部署库.
- 无需注册的COM 仅适用于开发人员参与我的经验.如果开发人员需要使用特定版本的COM文件(无论出于何种原因),则此选项尤为重要.详情见下文第5.4节.
- 除了COM之外,您还可以通过让安装程序开发人员在MSI设置中注册文件和MIME关联以及命令动词来解决自我修复问题.谨慎使用,并确保您的文件/ MIME关联是唯一的.
- 最后,您可以通过两个已安装的MSI文件之间的任何文件或注册表冲突进行自我修复.他们" 错误地共享资源 "并将其视为自己的资源 - 在冲突解决之前与之斗争.
- 某些自我修复问题不是由供应商应用程序或设置中的错误引起的,而是由计算机环境中的外部因素引起的,例如来自修补用户,脚本,病毒,反病毒或安全软件的干扰.有关详细信息,请参阅第3节.
处理问题应用程序的快速选项
如果你确定你看到的自我修复是由单独的MSI引起的(而不是由下面前面几节中描述的其他外部原因引起的),也许可以直接跳到第5节获取建议的修复和解决方法列表.
第5节中提出的大多数"解决方案"实际上主要是系统管理员技巧,它们无法解决根本问题 - 如上所述,真正的解决方案必须来自供应商.例外是"5.4:无需注册的COM",它实际上可以帮助开发人员 "屏蔽"他们的应用程序免受自修复问题.
如果你没有在你的机器管理员权限建议您尝试的"解决方案" 5.2,5.3或5.1(5.1通常需要管理员权限的尝试,但它是不复杂).这些是" 快速解决方法 ",其他更多参与.如果这些变通办法不起作用,请让您的管理员阅读其他建议.
了解Windows Installer自我修复
我之前已经详细介绍了这个问题,但它过于关注理解问题,而不是实际找到一个可接受的解决方案.您可以在此处阅读有关自修复问题的完整说明:如何确定导致重复Windows Installer自修复的原因？.
修复Windows Installer自我修复问题
要实际修复重复和无休止的自我修复,您可以尝试以下第5节中的建议 - 按复杂性和难度的顺序递增.在这样做之前,您应该验证自修复问题的真正来源.它可能不是由MSI文件引起的,而是由其他外部原因引起的(例如脚本或用户删除文件或防病毒阻止文件).
如果问题确实与MSI相关,您可以尝试禁用广告快捷方式和COM插件,使用无需注册的COM,从应用程序供应商处获取帮助,卸载违规应用程序,虚拟化软件包或完全破解缓存的MSI数据库和注册表(不推荐,只有专家帮助才能真正实现).这一切都取决于你的情况.如果脚本等外部原因出现故障,则必须消除此干扰.请参阅下面的详细信息 - 只需按照检查列表.
解决问题的第一步是确定问题确实存在于您的平台上,然后确定哪些应用程序首先触发自我修复:
1. 验证您的环境中是否确实存在问题.
- 这是一般总是能够以弄清楚是怎么回事,使有问题的自我修复,并有几个可行的解决方法,可以被利用来处理这个问题.但是,并不总是能找到一个好的,永久性的修复(没有供应商的帮助 - 如下所述).
- 因此,如果您是系统管理员试图找到自修复问题的修复程序,可能要确保在多台计算机上看到问题 - 特别是如果在开发人员身上看到问题,QA-甚至是测试电脑.
- 如果您只在一台计算机上看到自修复问题,则可以选择重建问题计算机.有效地消除而不是"解决"问题.有一个比较高的风险,你可能会看到问题又来了,虽然.如果你问我,不要重建,这不是解决方案 - 但我认为在现实世界中往往会做些什么.
- Be aware that an AD-advertised MSI install that is slow to install and keeps getting aborted by users can "look like" a self-repair issue for desktop support, but this is expected MSI behavior. Allow the install to complete once (it is possible to change the installer progress bar to disable the cancel button - something like
msiexec.exe /I "MyApp.msi" /QB-! for progress bar only with no cancel button and no modal dialog at the end).
2. Identify the culprit(s) for the self-repair.
- It is possible for a single application to cause the problem on its own, but typically there are at least two applications that conflict (they share some resource by mistake).
- The trigger for the self-repair is generally possible to find in your event viewer on the system where the self-repair took place. Follow these steps to open the event viewer:
- Right click "My Computer"
- Click Manage
- Click continue if you get an UAC prompt
- Go to the Event Viewer section, and check the Windows Logs
- Identify the offending application in the Windows Event Log by looking in the "Application section" of the event log and you should find warnings from the event source "MsiInstaller" with IDs 1001 and 1004.
3. Verify that external non-MSI causes are not causing the problem
- Anything that deletes files or registry settings, manually or automatically, can trigger MSI self-repair. Especially if you are messing around deleting stuff in the user profile or in the HKCU section of the registry.
- In most cases such triggers will only cause a single self-repair to run and then the problem is fixed (this is how self-repair is supposed to work and help users). Allow self-repair to run once and then launch the application again to test if the problem is gone. It should be, and your application should launch correctly from now on.
- Special case: Ironically you can sometimes fix a broken application by renaming its HKCU application key (in the user section of the registry) to actually force self-repair to run and install the application's default data in the user profile - if that data was accidentally deleted (this type of fix generally does not work on terminal servers).
- If the same file or registry entry is deleted again by automated means and self-repair results, you must eliminate or update the automatic process that is causing it and your problem is solved and you can stop reading. If you manually deleted the file again yourself, then you may suffer from bad memory :-).
- In summary cleanup scripts, logon scripts, cleanup applications or tinkering, overactive users can all cause this kind of self-repair.
- Finally viruses and also anti-virus software (and other security software) can block access to files and trigger self-repair that will never succeed.
- For an infected computer, just rebuild the computer. It will save you time overall.
- For anti-virus/security software problems, bring out your security guys to solve it. They may need to contact the vendor in some cases (particularly for false positives).
- Whether virus or anti-virus related, check the offending file on http://www.virustotal.com to verify whether it is actually a virus or just a false positive (which can be an even bigger problem for self-repair).
- Personally I have seen several anti-virus/security software related self-repair problems, but no real virus-related problems (so far). I guess viruses normally infect core system files rather than application files, and core system files are not to be deployed by MSI files (shared system files might be included in MSI files, but not core system files).
4. Contact the vendor(s) (or your own packaging department).
- Once you have verified that the self-repair problem is MSI-based and it is not your own software, the first thing to try is to contact the application vendor(s) and see if they have an updated installer to eliminate the problem.
It is important to try this option since all other options are "workarounds" and not real fixes. The problem can only be completely resolved permanently by changes in the vendor installer and possibly the application executable itself.
- Fix 1: The fix can be as simple as having the vendor remove privately installed but globally registered COM files with the appropriate, shared "merge module" to install the run-time correctly for everyone. These should install COM files properly to shared locations where they can be globally registered without side effect. Ready for everyone's use.
- Fix 2: If the vendor claims this isn't possible - then they should be able to provide a proper registration-less COM installation with properly isolated COM files installed to the main application folder. They should also take care of deploying any security updates whenever they would come along.
Important!: If the vendor either uses the correct, shared merge module to deploy files or provides an isolated installation using registration-less COM, then the problem should be solved permanently for everyone.
- The problem can also be caused by other issues, but very often COM is the culprit. Sometimes a cleanup of their MSI installer can resolve other, more obscure conflicts. If you know a good application packager, he/she should be able to quickly identify conflicts (and provide feedback for the vendor).
- Note that it is also possible that the self-repair is caused by erroneous (in-house) repackaging of vendor software. In that case you can fix your own packages via updates delivered by your own packaging/deployment department (and they should definitely be able to achieve this for most cases). This is in fact a very common issue.
5. Select a "workaround" or fix to deal with the conflict situation.
If the vendor(s) won't provide a fixed installer package, you need to find a "workaround" to deal with the situation. There are several options, and some "quick workarounds" should be tried before you delve into too much complexity. Here are some problem solving suggestions in order of increasing levels of difficulty and complexity:
5.1: Just uninstall the culprit(s).
- The absolute simplest fix is to figure out what application(s) trigger(s) the self-repair and just uninstall it, if that is an acceptable solution for your environment (it rarely is).
- This can be acceptable if there are two (or more) applications in conflict and one of them is rarely used or "optional".
- You can run the problem application on a virtual machine instead (see section 5.5). This would be my preferred "fix" for a very "misbehaving" application. All problems should disappear without any real debugging (which is costly).
- Plain uninstall is an option that is at least worth considering - some software can be very problematic in more ways than one, and should simply be rejected for use. Be sure to let the vendor know that the software was rejected as well. It might be the only way to make them take the problem seriously.
5.2: Remove Advertised Shortcuts.
- The first Windows Installer workaround to try is to remove "advertised shortcuts" (essentially a special type of shortcut that points to an Windows Installer application feature, and not directly to an executable or file). Read the linked article from Symantec for details on advertised shortcuts.
- Note that shortcuts can be created "anywhere" including in special folders such as the "Startup" folder. This particular location means a self-repair can be triggered by itself on system startup (without user interaction).
- Use an MSI viewer tool and open the system-cached MSI and inspect its Shortcut table to find all shortcuts. In order to find a list of all cached packages you can try this answer: How can I find the product GUID of an installed MSI setup? (open the package path specified in "LocalPackage").
- You then re-create a regular shortcut that points directly to the executable in question. This will "bypass" the most common trigger of self-repair (the advertised shortcut). In some cases this avoids the whole self-repair issue. It is worth a try.
- Be aware that even if this appears to work straight away, self-repair might still re-appear whilst you work inside the application (for example when you open a particular form). You need to "pilot" this fix with some users who actually use the application actively to make sure it is a good enough workaround for your environment.
- You have also merely eliminated the symptom of the problem, the registry or file conflict that caused it has merely been "bypassed" or "silenced" - it still exists, but this may be good enough if the applications exhibit no problems during operation.
- There is in fact a way to disable all advertised shortcuts on installation of any MSI package. You set the property DISABLEADVTSHORTCUTS (in one of the ways described in the link), and then all shortcuts will be created as regular shortcuts and they will not trigger self-repair. There are at least two problems:
- 1) The package could be designed to use self-repair to install userprofile files or HKCU settings. In this case this data will then never be added to the system as intended since self-repair will never run, and the install is effectively incomplete.
- 2) There is no guarantee that self-repair won't still occur - since it can be triggered by other advertised entry points such as COM invocation, file and MIME associations and command verbs.
5.3: Disable COM addins (if possible).
- If your problem is related to the loading of an add-in (for Outlook, Excel, Word or other apps like AutoCAD or similar), then there are no shortcuts to tweak - the addin is loaded on launch of its "host application".
- The easiest to try is to disable any addins you don't need in the addins dialog of the application in question (often Outlook, Excel or Word or similar) and see if this makes the problem go away. In some cases you are just disabling COM addins that users never used in the first place, and the problem has been eliminated.
- And, rather obviously, also try to disable addins that you actually need as well, in order to check if the problem can be related to its loading. If the addin is the culprit, you should continue down the check list to the next proposed solutions (next bullet points).
- I should re-iterate that the preferred solution would be a fix from the vendor (most often it would involve making the addin properly use the latest, shared ActiveX/OCX controls in question - other addins could still trigger the problem though, if they are also badly designed. You could end up dealing with multiple vendors - usually blaming each other).
- In fairness to the vendors, the problem can also be caused by bad corporate application repackaging - if you are on a corporate machine. Then you must deal with the packaging department for a fix.
5.4: Try registration-less COM
- Arguably this solution is more complicated than virtualization (which is described in the next bullet point), but I put it here since it might be a preferred option for some people.
- Registration-less COM is something I have rarely used, but it is said to be a viable solution: Generate manifest files for registration-free COM. This essentially bypasses the registry and activates private copies of the COM files controlled by manifest file(s) placed next to the application executable(s) - effectively shielding the application from COM registry interference (in theory). "Everything happens in the same folder".
- Your in-house packaging department might be able to use this to deal with "difficult vendor packages" to "isolate" their problems. However, I am not convinced registration-less COM will work properly without a few additional application tweaks contributed by the original solution developer, but I lack the empirical data to back it up. If it is an in-house app with source available, give it a test spin (and let us know).
- My main problem with this approach, is that it opens up potential security holes (private copies of COM files that will never be patched by Microsoft), if you don't make sure the isolated components are updated yourself. Updates would likely cause lots of manifest-rewrite work as well (but are these old COM files updated at all anymore anyway?)
- Note that registration-less COM, at least in theory, can be used for all COM related conflicts, whether they are VB6 executables, VC++ applications that use COM, etc... I am honestly not sure if it works properly for (office) COM addins (dlls) and VBA forms.
- Here is what appears to be one of the better MSDN articles on registration-less COM):