I have created a bundle using WIX.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Bundle Name="ClientSoft" Version="1.0.0.0" Manufacturer="Tests" UpgradeCode="GUID">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<MsiPackage SourceFile="file1.msi" Visible="yes"/>
<MsiPackage SourceFile="file2.msi" Visible="yes"/>
</Chain>
</Bundle>
</Wix>
I am installing only MSI files. The bundle will be executed with -silent option.
I would like to force a restart(without prompting) after bundle installation completion.
Adding -forcereboot does not help.
How can I force a reboot after all MSI files are installed?
EDIT:
'regular user' will not use the system, therefore I do not consider restarting out of blue as undesired behaviour - restarting out of blue is exactly what I need.
Burn Reboot Notification: As far as I know Burn will show a reboot prompt after installation if any of the embedded MSI files schedule a reboot (that can be done by scheduling the standard actions ScheduleReboot or ForceReboot - and Windows Installer will schedule a reboot by itself if a file can not be replaced during installation).
I believe the Burn bundle will handle suppressing the reboot until the installation is done - by virtue of the command line they use to invoke each MSI, but I am not 100% sure. There could be special concerns for ForceReboot. Just use ScheduleReboot, and condition it well - as explained here.
Moreover the whole bundle seems to refuse to uninstall if a reboot is pending. Not sure what happens when the bundle runs in silent mode, it seemed to kick off a failed reboot. Haven't tested too thoroughly.
Pending some testing. Need to do something else first.
Rant: I wrote a whole reboot-rant, just for you below :-). The gist of it: just do not reboot unexpectedly or spontaneously.
Unfortunately Windows Installer itself will spontaneously reboot when
run in silent mode, unless you specify REBOOT=ReallySuppress on
the command line - if a reboot is indeed pending.
Don't: Causing a spontaneous, unannounced reboot is actually technically easy (custom action, or an MSI run in silent mode that sets ForceReboot - or even ScheduleReboot without setting REBOOT=ReallySuppress on the command line - described here - in detail - or you can hard-code the REBOOT property to "Force" in the property table - this will also trigger a reboot without warning). Rebooting like this is logically and pragmatically unsound. Extremely so in fact.
Ethics for Rebooting: Rebooting a knowledge worker's PC is very serious, I have seen people sent out the door for less. This is nothing to be nonchalant about: Dozens of Visual Studio windows, heaps of half-written emails, notes in notepad, and the plague itself: missed chat messages and web pages without state management, etc... Beyond losing data (which still happens, though most apps save before closing), people lose context (obvious, but still) - it is as if someone took your physical desktop and swiped it clean with documents ending up on the floor and in the trash can (now politically correctly referred to as the "recycle bin").
There is more:
What if you reboot and there are many users logged on?
Someone could be careless enough to install on a server that needs careful management of reboots (for example: multiple servers need to be booted in a specific order for auditing and various purposes - yes, it happens and the air will be full of not so good words).
God forbid you reboot a terminal server out of the blue with the whole company logged on (not even sure it is possible).
The list could be made very technical - the strangest things happen. System administrators could for example make a batch file for "semi-automatic installation". In other words they kick of the batch file - it runs the MSI in silent mode with a few prepared settings and the box reboots without warning. Not sure what features have appeared in Windows to deal with this on server OSs.
What if you force an immediate and spontaneous reboot via a custom action and the MSI is one of many being run in sequence in a Burn bundle? Not sure what Burn does to handle this? It might have features to handle it.
The bottom line is this: your software could be thrown out of whole
companies for "behavior" such as this. Haphazard rebooting. It really can. As in "...if they do this, what else do they do that we can't live with".
Civilized Reboot: I am not sure of all the aspects here, but I would recommended something like this for software that can not work without a reboot:
Premonition: Announce before the installation starts that a reboot REALLY
is necessary after installation. Allow early exit. Helps everyone.
ReallySuppress: Do not ever disrespect an MSI file's command line set to REBOOT=ReallySuppress in order to suppress all reboots (this is a built in feature of msiexec.exe - Windows Installer engine - you can suppress all reboots scheduled by an MSI, theoretically - there are still hacks).
We need this working in the business and to eliminate the freebasing approach of doing whatever whenever in terms of rebooting.
The poor system administrators who have to deal with freebasing packages resort to desperate measures to prevent spontaneous reboots: Is there a really-really-really-don't-reboot parameter for msiexec?
Admins really go to these extremes to prevent reboots (removing system privileges for reboot to control what is going on). I don't recommend they do this since this can cause other, unexpected problems - technical hacks always do. Always side-effects. The right approach is to eliminate reboot hacking in packages. Isn't it? Or an update to Windows that really suppresses unexpected stuff like this.
Standard Approach: After installation Windows Installer itself will show a dialog to reboot. Allow this standard approach to be used. And as stated: respect reboot suppression for a silent install. Note that Windows Installer will show a reboot dialog - if files need to be replaced - even if you did not add an explicit ScheduleReboot command in your MSI file. Automagic.
No Soup For You: You can make your application refuse to launch before a reboot is done. Many ways to do so, maybe just scan for a file that needs to be replaced for example before you allow to launch. Opens up for potential launch bugs, so keep it simple. The EXE might not even get off the ground if there are necessary prerequisites requiring a reboot. I wish we could hide shortcuts added until reboot is complete (if reboot is really, really needed). Or a modal dialog that can't be dismissed without kicking off reboot? Loaded gun that. I prefer to not add any buttons to kick off a reboot in the application, I just state a reboot is needed and exit - if this is indeed necessary. Less to test for the QA guys?
Use /forcerestart instead. It's the Standard Installer Command-Line Options that Burn follows.
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:
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.
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.
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.
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.
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).
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. And in addition to a link, in image form as well:
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.
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".
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 (funny how a false positive can be harder to get rid of than real malware?). 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.
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.
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?.
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).
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).
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):
What could be causing MsiInstaller to continuously reconfigure applications (EventID 1035)?
How can I determine what causes repeated Windows Installer self-repair?
Serverfault.com: How can I determine what causes repeated Windows Installer self-repair?
MSI self-repair triggered for the non-admin user when Tabctl32 was installed via merge module
Diagnosing self-healing MSI
why does windows installer start up everytime i start up visual basic 6
Windows Installer self-repair can cause problems for both developers, system administrators and end users. Finding the solution can be difficult if you have limited MSI experience.
This is a Q&A-style answer intended as a check list for solving self-repair problems. Here are a few common problem scenarios:
Repeated Windows Installer self-repair might occur whenever you launch an application on your workstation. How can this be fixed, or how can components be disabled so it never occurs again?
A WiX installer may be deployed and you see repeated Windows installer self-repair whenever you try to launch the application.
When enabling or installing an MS Office addin, you experience continuous Windows Installer self-repair on application launch of one or more MS Office applications.
When working on legacy solutions in VB6 or VBA, self-repair kicks in for an unrelated product when you launch the main developer IDE.
When opening a form in Outlook, Excel or Word or similar applications, self-repair kicks off for an unrelated product from another vendor.
Keywords: Windows Installer launches unexpectedly. MSI displays unexpectedly. Windows Installer appears every time. Opening Application Starts Windows Installer. Windows Installer self healing. How does a package self-heal. MSI self-heal best practice. Windows Installer repair. Self-Repair. Disable Windows Installer. Windows Installer repeatedly runs. Application Shortcut launches installer instead. Windows Installer appears unexpectedly.
Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
Concrete Design Advice for your WiX / MSI File
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.
The answer below provides a checklist for solving any self-repair scenarios - from any vendor or source, not just your own. Check the answer linked above for your own MSI package design concerns.
The "Short Version" - Self-Repair Checklist
To permanently and reliably fix self-repair problems for everyone, developers and setup developers must be involved since the real fix must happen at the vendor level.
If you are in a corporate environment, poor-quality application re-packaging can also cause self-repair problems, and you should involve your application packagers to determine if the problem is from the vendor or not.
System administrators must know what they are looking at, and when no fix is available, use various workarounds to deal with the problem in the wild. Even end users can try some easy workarounds themselves (see section 5).
The essence of self-repair problems:
Most self-repair issues are COM-related, and there are two general fixes for vendors and developers: 1) use the properly deployed, shared COM libraries generally deployed via merge modules, or 2) use registration-less COM to "shield" your application from self-repair and compatibility issues.
Your setup developer can implement the merge module fix, developers must test. Merge modules are standardized, shared deployment libraries for shared files.
Registration-less COM only works with developer involvement in my experience. This option is particularly relevant if the developer needs to use a particular version of a COM file (for whatever reason). Details in section 5.4 below.
Apart from COM, you can also cause self-repair problems by having your setup developer register file- and MIME-associations and command verbs in your MSI setup. Use sparingly, and ensure your file-/MIME associations are unique.
Finally you can cause self-repair by any file- or registry conflict between two installed MSI files. They "share a resource by mistake" and will treat it as its own - battling it out until the conflict is resolved.
Some self-repair problems are not caused by errors in the vendor application or setup at all, but by external factors in the computer environment in question, such as interference from tinkering users, scripts, viruses, anti-viruses or security software. See section 3 for more details.
Quick Options For Dealing With Problem Applications
Perhaps jump straight to section 5 for the list of suggested fixes and workarounds if you are sure the self-repair you see is caused by MSI alone (and not by other, external causes as described in the first few sections below).
Most of these proposed "solutions" in section 5 are really mostly system administrator tricks that don't fix the underlying problem - as stated above the real fix has to come from the vendor. The exception is "5.4: registration-less COM", which can actually help developers "shield" their applications from self-repair problems.
If you don't have admin rights on your box you are advised to try "solutions" 5.2, 5.3 or 5.1 (5.1 will generally require admin rights to try, but it is non-complicated). These are "quick workarounds", the others are more involved. If these workarounds don't work, please ask your admin to read the other suggestions.
Understanding Windows Installer Self-Repair
I have written at length about this issue before, but it focused too much on understanding the problem rather than actually finding an acceptable fix for it. You can read the full explanation of self-repair problems here: How can I determine what causes repeated Windows Installer self-repair?.
Fixing Windows Installer Self-Repair Issues
To actually fix repeated and endless self-repair, you can try the suggestions below in section 5 - in increasing order of complexity and difficulty. Before doing so, you should verify what the real source of the self-repair problem really is. It might not be caused by MSI files, but by other, external causes (such as scripts or users deleting files or anti-virus blocking files).
If the problem is indeed MSI-related, you can try to disable advertised shortcuts and COM addins, use registration-less COM, get help from the application vendor, uninstall offending applications, virtualize packages or full on hack the cached MSI database and registry (not recommended, and only really possible with expert help). It all depends on your scenario. If external causes such as scripts are at fault, you must eliminate this interference. See details below - just follow the check-list.
The first steps for problem solving are to identify that the problem really exists in the wild on your platform, and then to determine what application(s) trigger the self-repair in the first place:
1. Verify that the problem really exists in your environment.
It is generally always possible to figure out what is going on to cause the problematic self-repair, and there are several viable workarounds that can be utilized to deal with the problem. It is, however, not always possible to find a good, permanent fix (without vendor help - as described below).
Accordingly, if you are a system administrator trying to find a fix for your self-repair issue, perhaps make sure the problem is seen on more than one computer - especially if the problem is seen on a developer-, QA- or even a test computer.
If you only see self-repair problems on one computer, an alternative might be to rebuild the problem computer. Effectively eliminating rather than "solving" the problem. There is a relatively high risk that you might see the problem again though. If you ask me, don't rebuild, it is no solution - but what tends to be done in the real world I guess.
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.
You can find a lot more details on how to do this in the more elaborate answer here: How can I determine what causes repeated Windows Installer self-repair?. Look in the "Finding the trigger or culprit for the self-repair" section.
You can also try the advice from independent deployment specialist, MSI-expert and MVP Stefan Krüger. He has an article about the same self-repair issue. And he crucially discusses the actual event log entries and what they mean. Please read about the actual debugging procedure there.
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): https://msdn.microsoft.com/en-us/library/ms973913.aspx (there is even a downloadable MSI with the samples - which ironically seems to trigger an error for me on launch).
Personally I would probably rather try a virtual package using APP-V rather than trying to use registration-less COM (see next bullet point).
It should be re-iterated that rather than "shielding" your own application - the correct vendor fix is to stop deploying private copies of shared COM files that are erroneously registered system-wide, and start installing them as intended using the appropriate merge module for deployment.
5.5: Virtualization (APP-V, Virtual Machine, etc...).
Apart from uninstalling or disabling components, the simplest fix is arguably to use virtualization to "isolate" the applications that conflict. If you still want the applications on your main SOE (Standard Operating Environment), you could try to use a virtual deployment package (APP-V). This is an application that is basically installed on demand (on launch) and runs "sandboxed" or isolated from other applications on the system.
You can also use a virtual machine via systems such as VMWare or Microsoft Virtual PC to run the problematic application(s) in their own operating system. Often people have admin rights when using virtual machines, but don't on their main SOE system (main workstation). Many developer applications are more effective to use with admin rights, so this solution might be particularly useful when dealing with development teams and their requirements.
5.6: Windows Installer tweaking - (Experts only!).
If the problem is very serious for your desktop environment and none of the options above work, you can try to fix the problem at a Windows Installer level. It might be worth it if the addin (or whatever other software) is crucial to have available on the company's main PC environment.
Essentially what you need to do is remove offending entries from the system cached MSI and/or the registry (disable advertised entry points such as advertised shortcuts, COM registration, file associations, MIME associations or command verbs, etc...).
This is very involved and not good practice to do, and there are some side-effects (for uninstall, resiliency, etc...), but it is the only "last resort" that I know about.
In these cases you would be advised to contact a deployment / Windows Installer expert and have them analyze whether a "fix" is possible. It can work, but don't expect miracles.
If you insist on debugging yourself, you need to get hold of a tool to open cached MSI files on the system (such as Orca, Installshield, Advanced Installer or similar) and you need to "hack" the database - not recommended.
5.7: Windows Installer zapping - (Not safe!).
I am including this "option" for completeness and "historical purposes" if you like. It was never a good option, and is now very unsafe on newer versions of Windows.
MsiZap.exe was a Microsoft SDK tool meant as a last-resort tool for developers to clean out failed MSI installs or uninstalls, it was never intended for widespread use. It allowed the complete "dirty unregistration" of any MSI package. MsiZap.exe is now deprecated, unsupported and unsafe to use. Use only on throwaway virtuals, if at all.
Back in the day a common "system administrator trick" was to use MsiZap.exe to "zap" a whole Windows Installer package from the system. Besides leaving your system incurably dirty, it also removed all self-repair problems for that application.
The junk that is left behind after running MsiZap.exe includes essentially everything (except the actual MSI database registration). All files, all registry entries (including COM), SharedDll ref counters (which really screw up things on reinstall), services, anything really. You will never be able to uninstall properly. In most cases you will fail to install upgraded versions of the same application without side effects. Many people actually see more self-repair problems afterwards when trying to install on top of the dirty state.
Rob Mensching, creator of WiX, Orca and all things Windows Installer has a blog post on the perils of MsiZap. MSDN describes another bad side effect: All program update information is removed when you use the Msizap.exe tool to uninstall a program from a Windows-based computer
6. Summary & conclusion
Step 4 - contacting the vendor for a fix - is the only "real fix" in my opinion.
All other proposals try to deal with the problems that result from vendor errors, rather than provide a lasting solution.
The real-world problem is that many vendors tend to blame each other, so you might be out of luck. And some vendors who do it right, do suffer from the design errors of others.
Proposals 5.1, 5.2, 5.3 are non-complicated "workarounds".
Should be safe to try for everyone.
Proposals 5.2 and 5.3 should be possible to try even without admin rights.
Proposal 5.4 - registration-less COM - is a rather involved, potential "fix".
Developer involvement might be required to find all dependent files to "isolate".
In my experience this is the kind of project that ends up taking days to try out (even with expert help) - without a real guarantee that it will eventually work.
I hear conflicting things from experts, some have succeeded, some say it fails. The people with access to the solution source seem to succeed.
Personally i don't like it for the potential security holes it opens up, and any new file versions to deploy could mean a new round of manifest re-authoring (I believe).
However the COM files in question are so old now that it is rather unlikely that they will see any security updates made to them anyway. I suppose these COM objects are mostly used for .NET interop nowadays.
Proposal 5.5 - virtualization - is a common option these days and should probably be tried before 5.4 if available in the environment. As the saying goes, "virtualize, seriously".
I honestly don't know (lack experience) if virtualization is viable for (office) addins. Please update if you can confirm.
Executables can definitely be virtualized.
Proposal 5.6 - "cached MSI tweaking" - is a "hack" that can work "good enough" when done right by deployment specialists.
There are some "side effects", particularly for uninstall - and also for "resiliency", but these should be manageable if done right.
It is the "real world" - nothing is "clean".
And proposal 5.7 - "zapping MSI" - is an unsafe, deprecated "legacy hack".
There are several side effects due to the system's "dirty state".
Total corruption of the MSI database has been reported after running MsiZap.exe.
There must be problem inside your package.
To find issue.
Clear eventlog - application.
Run your application as user with AdminRigths
Application should run after self-repair. You can run twice, if self repair will not appear,after when you run second time, it's meant that there is problem with component that want to create entry inside MachinePart like HKLM or Programfiles or Windows folder.
Open your eventlog and look for entry with source MSIInstaller.
Entry with warning will give you information what feature and component will cause self repair.
If you can show us here log from that warinig we can tell you more about your problem, but in general message inside eventviewer is clear and says what resource is missing.
Since it happens every time you launch your app (and I assume that you allow the repair to run to completion) the most likely cause is that the app removes something that is "protected" by Windows Installer, such a registry entry or a file. The shortcut initiates the repair mechanism to reinstall the missing item, and the MsiInstaller entry will tell you what it is.
In general, repairs are a good thing because they allow the user to repair the installed product if it's damaged. If, by design, there are resources that are installed but not required to be repaired then set the Component Id to null in your WiX, because that is the documented way to prevent repair of certain files, see ComponentId remarks here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx
I have an installer whose initial installation will be done by a human, but updates have to be done automagically.
Handling installer failure is a problem. I have to plan for the installer to fail: I use the <RollbackBoundary/> element in the Bootstrapper to get to a good state, and then I use both the WiX log and a log of my own devising to document the failure.
However, that's not good enough.
There's a program (let's call it X.exe). If-and-when the installer fails, I need to roll back to the state that the installer was in before the installer started and:
Restart X.exe or
Restart the target machine so that X.exe can start (I install X.exe into the startup folder of the target computer; this is also what I do for a successful install -- restart the target machine).
Deal with the problem in some as-yet unforeseen way.
Is there anything besides Logging that WiX can do for a installer failure? Is there a condition that is set that I could catch, or... anything?
I learned WiX through the fantastic book WiX 3.6: A Developer's Guide to Windows Installer XML (by Nick Ramirez), but I can't find anything to solve my problem there, nor can I find it on the interwebs.
I'm hoping there's something obvious I missed. Does anyone know how to deal with installer failure besides logging them and calling it a day?
Based on the lack of answers and lack of finding the answer to my question in existing resources, I realize that I'm simply asking Windows Installer to do too much.
I was hoping that there would be a way to do something like:
if (installation fails)
{
do something (besides rollback and logging)
}
I wonder if other installation programs provide functionality like this? Or if there's some other way to get a target machine to do something if the installer fails?
There is, in theory, but the whole area of rollback is fraught with caveats. Consider the "installation failed" dialog box and how it differs from a success case: you could run a custom action on that dialog box. But that's only if there's UI. So maybe do things from the rollback action. But what if Rollbacks are disabled? Your only mildly robust solution will be outside of the Windows Installer package.
So in your X.exe, make sure to capture the return code so you can identify a success, a cancelation, a failure, and various reboot required states. If it's a failure, then consider applying your external fix (your reboot, or whatever). If you didn't write X.exe, consider doing so, or writing something that will call X.exe.
But really PhilDW's comment gets to the core of it: rebooting on failure is not an expected behavior for an application installer. (Reboots by application installers in general are advised against.)
I'm developing a windows application (using vb.net) that can install various versions of runtimes like vc++, Direct X, .net frameworks etc on a PC. My program must be able to to run the runtime installers (msi & exe) one at a time in the background and do the following:
1.Check weather the runtime is already (previously) installed or not.
2.Show the installation progress in a progress bar in the main form of my program.
3.And at last get the return code (exit code) from the installer to indicate weather the installation was successful or not.
What are the codes required to perform the above tasks?
Also I want to know what are all the possible return codes(values) an installer can return.
All of those redistributables might have different command line options, so it's not likely to be one answer for everything.
It's not clear how you can get the installation progress. It's almost certainly impossible or very difficult. You're asking how you can run a program that will "steal" the output of some other program, and in many cases that will be Windows Installer. If I had a program that fired off a Windows Form program, then you're asking "how can I get the content of that program and steal the output messages". That's not an install question, it's a Windows messaging/windows message loop question.
The detection methods used by those setups are coded internally (or configured as internal data), so you're also asking how the code in all those programs detects that the dependency isn't installed (on multiple OS versions and 32-bit and 64-bit), and some of that might be available on the web but it's unlikely that it is readily available for every redistributable.
You might also have an issue with EULAs. Some redistributables need a EULA to be accepted and might not install unless it's accepted, or some may have a command line option that includes something like (just an example) ACCEPTEULA=1.
Basically you should:
Find the command line options available for all those redistributables to see if they have an option that displays only progress, then let them show that.
Similarly, see if they have documentation that tells you if the exit code means success or not.
Don't bother trying to find all the detection methods for everything - just run the redist, and if the target is already installed it won't do anything.
Finally, you are re-inventing the wheel. WiX, the Bootstrap Manifest Generator, InstallShield, Advanced Installer (and so on) all provide bootstrapper programs that already do this as prerequisites for installing software. Nobody writes code to do this any more because there are existing solutions.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa376931(v=vs.85).aspx
1638 for already installed. 0 for successful installation. Yet mind 3010 which stands for success but pending reboot.
About showing progress in parent window .. this may be not a trivial task. Hopefully someone else can give you a hand with that.