I am creating a WIX installer bootstrapper (with DisplayInternalUI="yes" on the msipackage), but it hangs when there are other installations occurring at the same time.
If i run the MSI file on its own using msiexec I get a windows installer error
"Another installation is in progress" message (i.e 1500 MSI error message) - and I presume this is hanging my install.
Therefore what I am doing is seeing if I can lock the _MSIExecute mutex just after the user presses the Install button (i.e. before the ProgressDlg). If I can lock the Mutex then there are no other installs in progress - therefore it is safe to proceed with the install (i.e. the execution phase) . If not the installer shows a cancel button (and no other buttons) - so the install will not proceed.
I was wondering if there was a way of preventing the "Another installation is in progress" error message (and other messages) from hanging the installer.
Simpler explanation from serverfault.com
No MSI Concurrency: Why are there other installations happening "at the same time" - or in other words concurrently? I am not too potty-trained when it comes to WiX Burn bootstrappers, but I am wondering if the MSI in question contains any custom actions which kicks off other MSI installs? This is not allowed for MSI packages. You can not have two concurrent InstallExecuteSequences running at the same time. Hence you can not kick off an MSI from within an InstallExecuteSequence. Some people try to kick off installs from the InstallUISequence, which is also very unadvisable for many reasons - for one thing it won't run at all when the setup is run in silent mode. I also suspect potential issues with elevation, and unexpected setup failure if you set check exit code for the custom action, and that kind of stuff. It always permutes. The basic rule of thumb to remember is: Custom actions must never launch other MSI installations. The WiX Burn bootstrapper basically specifically exists to allow you to run MSI files in sequence - and not concurrently - but it is also more: it is a combined bootstrapper, chainer, downloader, etc...
Mutex: Strong words, but if you know what is good for you, you will stay away from MSI mutexes. Save yourself! :-). MSI is a technology which fights back, and you will be fighting windmills for real if you take the fight. That is all I can say to warn you. It really is impossible to deal with unless you follow the basic rules, which in this case is one installer running at a time. The WiX guys could deal with it though - leave it to them - and use their tool propery (WiX Burn). Though the technical details are unclear to me, they will certainly have features implemented to do exactly what you describe (check if the system is ready for installation).
Suspended Installation: It is also possible that there is a suspended installation on your system that needs to be undone before you can install MSI files at all. Can you try to install another MSI file and see if it runs correctly? I am not 100% sure this is the right link, but you can also try: Fix problems that block programs from being installed or removed.
UPDATE: With regards to _MSIExecute Mutex. See towards bottom for technical info on checking the current Windows Installer status using QueryServiceStatusEx. Heath Stewart suggests another way (sample C++ code).
Also, some pre-existing, related answers:
check for windows installer mutex availability
How to detect a running MSI Installation
Windows Installer always says “Another program is being installed”
First some comments on the issue at hand (virtuals updating and pending reboots):
Windows Updates In Progress: If you are dealing with the situation where Windows Updates are being performed in the background and MSI installations won't run, then it is possible that WiX Burn might hang whilst checking whether a system reboot is pending. I have seen issues like this before (see "technical issues" below).
Real Fix: If this is the case the only real fix is to let the Windows Updates finish and then reboot and persist a new virtual machine state and then install your package. This is the only sane fix - in my opinion. Not what you want to hear :-).
Dirty "Fix": I suppose you could also stop the Windows Update service to prevent Windows Updates from installing, but my guess is that your virtual will be infected with malware eventually if you do this, and then you have the horrible situation that you may accidentally persist malware in your virtual that is then resurrected regularly and not detected by security software (which often does not scan virtuals). This might be one of the worst malware vectors in existence due to the difficulty of erradicating it and discovering it (in the same league as malware on read-only media and malware checked into source control systems - there might not be an easy way to get rid of it). Well-meant advice (the kind that is never wanted - we all live in reality): please do not disable Windows Update on your virtual without a proper consideration of consequences. Corporate-wide I would never allow such a thing - only as exceptions for specific users who have testing needs beyond normal - and the virtuals would be forcibly malware checked regularly. Which reminds me to check what security software can scan offline virtuals properly. More research to do. Funny that, writing stackoverflow answers always teaches me what I don't do properly myself! Not good :-).
Technical Issues: As to the technicalities. I have seen issues before where WiX Burn hangs because it specifically tries to avoid installing on a system that is being updated:
WiX behaving badly on XP machine with windows update issues
How do I reference the Reboot Pending Property in Burn (WiX) (recommended)
Maybe check if that little VBScript in the linked answers (or equivalent COM call in whatever language you want) will tell you if the system is not ready for installation?
The Simple Hack?: Not verified, but maybe you can check the registry key / value (not sure whether this is a value or a key): HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer : InProgress - it should be present to indicate an active Windows Installer session - as far as I know. I think this is better than trying to handle mutexes and other OS fundamentals.
Strangely I am not aware of any MSI API calls that will tell you whether there is an active installation session (mutex set). The only thing I can see is a Win32 function (i.e not COM automation): MsiBeginTransaction (a very recent addition to the MSI API, 4.5 up only).
There is also this: MSDN: _MSIExecute Mutex - suggesting to use QueryServiceStatusEx and check whether the value of dwControlsAccepted is SERVICE_ACCEPT_SHUTDOWN. I have never tried it. Frankly I would try to check the above registry key instead.
If Windows Update is your main concern, then you'd use the Windows Update Agent API to detect if there is an update in progress. I think you'd need to run it from your own bootstrapper before attempting to install the MSI. The general C++ idea is as follows:
#include "stdafx.h"
#include <wuapi.h>
#include <iostream>
#include <ATLComTime.h>
#include <wuerror.h>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
HRESULT hr;
hr = CoInitialize(NULL);
IUpdateSession* iUpdate;
IUpdateSearcher* searcher;
IUpdateInstaller* iInstaller;
ISearchResult* results;
BSTR criteria = SysAllocString(L"IsInstalled=1 or IsHidden=1 or
IsPresent=1");
hr = CoCreateInstance(CLSID_UpdateInstaller, NULL,
CLSCTX_INPROC_SERVER, IID_IUpdateInstaller, (LPVOID*)&iInstaller);
VARIANT_BOOL Busy;
hr = iInstaller->get_IsBusy(&Busy);
etc
Basically the IsBusy property tells you if an update is in process.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa386502(v=vs.85).aspx
The discussion thread here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-Updates-either-pending-or-running-causes-our-installs-to-fail-td7598536.html
also has a better code example. I'm not aware of a managed code interface or built-in WiX support.
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 simply need to install multiple instances of my application saving them in different folders, with no shortcut on desktop.
In other words, when the App is already installed in a Folder, if I double-click the .msi file once again, the installer shouldn’t ask me if I want repair or remove my App, but it simply should permit to install it in a new folder.
How can I solve this problem?
I used to work with this kind of installations before, and I would agree with #Nikolay - it is rather an exception, than the rule when it comes to Windows Installer based installations. Component rules are often tricky to follow, and multiple instances aspect adds some complexity on top. So, think twice before you go this road.
Being complex, it is still possible. Years ago I published the article of how to start authoring multiple instance installations with WiX 3.6. Note that this version of WiX simplifies it significantly. It's not a short read, so here is a quick digest:
You won't be able to achieve the "install each new instance with double-clicking MSI file" behavior. You have to have a bootstrapper - something that passes correct command line parameters to msiexec.exe.
Don't try to support unlimited number of instances - try sticking with reasonably big number. Do you imagine someone installing your app 10 times on a machine? 50? 100? Make a sane choice - this will be the number of your <Instance/> elements.
Although you only have to decorate non-file data components with MultiInstance attribute, I don't think it will break if you add it to all of your components.
Although I explained the patching of multiple instances in that post, I would only use it in production if I had no other choice.
What you are asking for is not normal in Windows. Normally, each program (product) is installed only once. I.e. each installation package has it's ID (called "ProductID"). If that ID already registered in the system as installed, the system will not allow you to install the second product with the same ProductID, but start change/remove.
What you can do:
Don't use Windows Installer (and WIX), use ZIP for example, or some self-extracting archive, or some other program which does not register installed product in the system.
Use command line to change product id before installing if you want MSI and Windows Installer for whatever reason. Try googling on "use transforms to install the same MSI multiple times". Thus you can have the same MSI per-transformed before installation, so that it looks as a different one to the system.
Install per-user, if that's good enough for you (i.e. don't install to Program Files, install to user folder)
Maybe there are other options...
I have a working WIX Bootstrapper that does install the software I need it to install. However On Windows 8 At least, there is a 16 minute period where it appears to do nothing. Looking at TaskManager, I see no processes taking resources from the Bootstrapper (that I can tell). For some reason about 15 minutes into it it will just finish the install:
[0E6C:0E90][2014-01-24T13:49:45]i299: Plan complete, result: 0x0
[0E6C:0E90][2014-01-24T13:49:45]i300: Apply begin
[0E04:0DD8][2014-01-24T14:05:35]i360: Creating a system restore point.
[0E04:0DD8][2014-01-24T14:05:50]i361: Created a system restore point.
Any ideas as to why this is taking so long, after the log says "Apply begin"?
Note: Behavior does not happen on XP or Vista, Or 7. I think it has something to do with "pausing" Windows updates during installs. Does anybody know anything about that?
Thanks.
This sounds like a timeout of some sort. I assume there are multiple MSI files, and some of them may be tagged with a launch condition (look in the LaunchCondition table) which disallows installation on Windows 8? Maybe worth a check at least. Try launching each MSI manually in sequence and see if you receive any error messages. There may also be missing runtimes such as .NET, C++, Crystal Reports or similar. Often the MSI will display an appropriate error message to tell you what is wrong.
In case you find nothing when launching each MSI, you should make verbose log files for all of them so there is something to work with for debugging. If you are unfamiliar with msiexec.exe (Windows Installer Command Line Interface), you can use the tool described in this thread: installation using msi.exec open help options every time . It should be easy to enable verbose logging using that tool.
Also check this thread: How to skip a bootstrapper or ignore fail in Windows 8?
And the documentation might be useful: http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/
I never could find a parameter or condition in my installer that would cause this. However the effect went away when I used insignia to sign my wix projects (MSIs and a bootstraper). Prior to that I had been using the signtool by itself to do the signing.
How can I create an automated Installer for a program that has a regular Installer with questions like:
Install Directory,
Accepting License,
Creating Icon on Desktop
etc...
Assuming that I am OK with building an Automated Installer for every program I want to separately, Or i want to put files in a Self Extracting Archive and run the Installer after unpacking.
Do I need a third party program for it? Should I use Command Prompt? Do I need to learn Lua? (I'm learning C#)
EDIT:
To clarify I'll use an example:
Let's say i wrote a program but that program has a requirement, like
DirectX, or Adobe Air, or Maxthon Browser.
I wrote my program in such a way that I have to be sure that that is
installed in a very specific Drive/Folder on the PC or with some
specific preferences/parameters.
I include an installer for this program, but I want to specify where
it gets installed on the PC and with what parameters.
Preferably Installing this requirement right after or during the
Installation/Extraction of my own program.
I'm looking for a way to be able to run the Installer of any given program and navigate through the install wizard of it with out the user having to/being able to change the settings I need (with the foreknowledge and permission of the user of course).
It doesn't need to be silent install or anything.
I have rewritten my answer.
Your mentioned setups requirements seem very common to me for the class of installation programs (setups) and not at all unusual.
Generally you have two options:
You write everything on your own, you create the install dialogs, the way the settings are saved, and so on. Then you are fine with C# (or any other language).
It is quite uncommon to do so, because it is time consuming, and you are reinventing things which have been solved in standard ways several times. Moreover you will fall in common setup error traps which are maybe already captured (or at minimum documented) if using tools.
If you want to use a tool, it is your first decision, if you want a tool based on MSI (Windows Installer) or not. MSI is the most powerful and most industrial-accepted setup technology in Windows, but it is a quite complicated matter, and no tool can shield this 100% from you. Google for WiX (Open Source) or InstallShield as starting points for MSI tools but there are of course more.
Some tools are already integrated or integrateable in Visual Studio for example.
Selfextracting tools are a starting point, but the following tools offer far more and are a good intermediate way between the extreme points SFX and MSI:
InnoSetup
(has also a home here on SO).
Nullsoft Scriptable Install System (NSIS) on SourceForge
One self extracting program in Windows I want to mention, because it is not widely known, that "IEXPRESS.exe" is already included in the OS.
Concerning your special question of navigating through the install wizard:
Every mentioned tool has ways to save install settings and of course is deciding which settings are changeable by the user part of the 1*1 of setup creation. With the tools you can design the install dialogs like you want consisting of the parts you want.
I hope I got your point.
P.S. While most tools have kind of a scripting language or something similar included, you are normally free to extend the installation process with your own actions written in nearly every programming language you like.