I have MSI installer which installs product and this product has several widely used API dll's.
These dll's may be loaded into processes that I cannot control during upgrade (for instance, I cannot ask user to close explorer.exe or svchost).
So, during MSI upgrade these dll's are locked and cannot be upgraded without reboot. I need to make it upgradeable without reboot.
These API dll's are very stable and it is acceptable to leave old copies working in old processes when new versions of these dll's will be loaded into new running processes.
So, when we didn't use MSI then we just used standard trick - rename file, mark it to delete on reboot, write new file.
What is the best way how to do it in MSI?
Should I create custom action which will do this standard trick?
Or maybe MSI has some better way to do it?
Thank you!
The processes are "locked" because they're in-use, and you can't change an executable file while it's running; there is no "unlock" but to stop using the file. So either you kill the processes now or use the PendingFileRename key to change the file after a reboot...
You could perhaps try to kill the handles/threads that explorer.exe et al have to hold onto your DLLs (using a custom action), which might work for a minute... but that would ensure that (a) your newly upgraded DLLs won't work until after a restart either, and (b) you've probably made the user's computer unstable and Explorer could crash at any moment. Either way, the end users would not be pleased with your software... must worse than they would be annoyed at having to reboot.
Related
My Wix installer worked installing my program, but it's broken for uninstallation. A file is removed too early, and it's needed further down the line. The uninstaller fails and reverts its changes.
This means I can't remove the package from my machine, and hence can't install any further builds of my installer (a considerable inconvenience). How can I force removal of the package?
Update, Stein Åsmul: Injecting this newer list of cleanup approaches.
Find your package in C:\Windows\Installer, where Windows keeps copies of installed MSI packages. The names are generated randomly, so you'll have to look at the creation dates of the files.
Open the MSI file with Orca. (Unfortunately there is no simple download for the orca installer. You can get it by installing the "MSI Tools" of the Windows 10 SDK, and then searching for orca.msi in C:\Program Files (x86)\Windows Kits.)
Delete the offending custom action from the CustomAction table
Now you should be able to uninstall the package.
UPDATE: You can find the actual cache MSI file using Powershell. That was for one package, you can also get for all packages (scroll down to first screenshot).
This command usually works for me:
msiexec /fv installer.msi
It somewhat recaches the installer, so you can try again with a corrected one.
One time this command didn't work and I had to use Microsoft FixIt. It solved the problem (quite a shock for me).
Depending on the exact reason of the behavior you described, you might have at least a couple of options.
If the reason of the failure is a custom action which runs on uninstall, and this custom action is conditioned with some properties you can influence upon, you can try to pass the desired value via the command line:
msiexec /x {YOUR-PRODUCTCODE-HERE} RUNMYACTION=false
In this sample RUNMYACTION is a Windows Installer property which participates in a custom action condition, and if you pass false as its value, the action won't run.
Otherwise, you can fix the logic (or just disable the custom action explicitly) and build the new MSI package. Then upload it to that target machine, and run like this:
msiexec /i YourPackage.msi REINSTALL=ALL REINSTALLMODE=vomus
Here YourPackage.msi is a new fixed package, REINSTALL=ALL instructs the msiexec to re-install the product using this new package, and REINSTALLMODE=vomus (the v part of it) will re-cache the MSI package and you'll be able to remove it the normal way afterwards.
A side note: you should test your installation on a virtual machine in order not to risk your real one.
FYI: In Windows 8.1 the installers have been moved here: C:\ProgramData\Package Cache\
If you are really desperate and all solutions above don't work try
msizap.exe
This will erase all that your installer put on a machine
LITTLE WARNING
Don't run msizap without knowing what options you want to run it with (for a list of options run msizap /? first).
I used this little tool also from Microsoft
https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
Basically this tool can be used to "repair issues including corrupted registry keys that block you from installing or removing programs"
What it fixes:
Corrupted registry keys on 64-bit operating systems
Corrupted registry keys that control the update data
Problems that prevent new programs from being installed
Problems that prevent existing programs from being completely uninstalled or updated
Problems that block you from uninstalling a program through Add or Remove Programs (or Programs and Features) in Control Panel
It can be used for:
Windows 7
Windows 8
Windows 8.1
Windows 10
I usually just look for <Your Installer's Name>.msi or <Your Installer's Company Name> in the registry and delete some of the uninstall keys from some of the Products under the Windows installer trees and everything usually works fine and dandy afterwards, although this WOULD leave some stuff lying around like cached installers and possibly tons of other registry keys for each file installed, etc. but its ALWAYS worked for me when developing installers because honestly, who cares if one MSI is left over and cached somewhere? You're using the machine for development anyways, right?
I have created an MSI installer package in Visual Studio 2008. The problem is that after install, if I delete ANY of the installed files. This is not my intended behavior for my installer package. My File installation properties are:
PackageAs vsdpaDefault
Permanent False
ReadOnly False
Register vsdrfDoNotRegister
System False
Transitive False
Vital False
If this is trivial, please forgive me. I can't believe I have not been able to get Google to give up the answer. :)
Windows Installer is a deployment technology, its job is to install the specified files and registry settings and keep them in the specified install locations and to ensure they are the right versions - self-repair or resiliency is a mechanism to that end. Its operation conflicts with a developer's need to exchange files on the fly for debugging, development and testing.
As a developer you may be interested in deploying your MSI and then deleting or replacing files on the fly to debug things. In these cases MSI can be a nuisance because it never stops doing its job and will reinstall the correct files. This is called "self-repair" and can be spectacularly annoying! :-).
There are a lot of ways to work around this, MSI is quite complex. Since the "self-repair" is normally invoked from an "advertised shortcut" the easiest way to avoid this MSI feature is to launch the EXE file directly from the file system and not via a shortcut. This bypasses the MSI self repair mechanism for all but the most complex EXE files. You can also manually create a non-advertised shortcut on the desktop that will not trigger a self-repair (right click and hold executable and whilst holding down the right mouse button, drag-and-drop to desktop and release button over an empty spot and click "Create shortcut here").
For the record self-repair is triggered by "self-repair entry points" for key-path validation. They include advertised shortcuts, file associations, COM registry data among other things.
There is a lot more to self-repair, or resiliency which is its official name, please check this comprehensive article on self-repair problems to find ways to resolve your specific problem. It is a long article, but it should be worth the read if you have self-repair problems.
UPDATE, October 2018:
Self-Repair In Detail: More than anyone wants to know about self-repair:
Self-repair - explained
Self-repair - finding real-world solutions
Self-repair - how to avoid it in your own package
Links:
Similar: Visual Studio 2015 msi build initiates another installation
RestartManager causes worker role to restart
What is the use of Repair option in a msi installer and what does it really do (internally)?
Disable MSI auto-repair on installed program
It's by design, known as "resiliency": http://www.msifaq.com/a/1037.htm.
I know I am late to the party on this, but I have found that adding 'NeverOverwrite="yes"' to the Component definition of the file(s) that are intended to be modified after the install, stops the self-repair from undoing my changes.
This has all but solved my self-repair issue. I added this to all configuration files and batch files within the MSI.
How can I log only the changes causing a MSI file made by Installshield 2008 to reinstall via "self-repair"?
What is the reason behind self-repair?
How do I disable self-repairing of MSI using Installshield 2008?
Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
Alternative Answer Available
UPDATE:
There is a shorter, more "solution focused" answer available, perhaps try it first. This answer focuses on "understanding self-repair" rather than explaining the steps to take to eliminate the problem. You might want to read the first section of this answer as well.
Unexpected Windows Installer self-repair issues - Quick Fix?
This "article" has gotten large and somewhat unreadable. Here is a newly written preamble - the short "workaround version" for fixing unexpected self-repair (often found in VB6, Visual Studio, MS Office, MS Outlook, AutoCAD, etc...)
If you experience unexpected self-repair, the first thing you can try is to manually create a desktop shortcut directly to the application executable you are launching when the problem occurs. This bypasses the most common trigger of self-repair, "the advertised shortcut". If this works your problem is "solved" (or avoided). Here is a quick, fleshed-out explanation
If the problem still occurs, or your problem is related to the loading of an MS Office, MS Outlook add-in or similar (that you can't launch via a shortcut), then you most likely have a COM registration conflict on your system, and the fix is much more involved. The easiest to try is to disable any addins you don't need in the addins dialog of the application in question and see if this makes the problem go away
If you still see problems, then you most often need to debug a genuine COM registration conflict (or conflicting file/MIME associations, or command verbs). This normally involves (at least) two conflicting applications on your system that "fight it out" updating the registry on each launch after the other application has run (always launching one of the apps will not trigger the self-repair - the conflict surfaces when you alternate between applications). It is also possible that permission problems cause the same application to fail to update the system and it keeps trying endlessly by repeatedly running self-repair. And there are further possibilities, more details below
The "real fix" is to contact both application vendors and ask them for a fix for the problem (since a fix often requires a fix of both vendor MSIs), but in my experience this is rarely successful. Do try it out though - since this is the way to help everyone with a long-standing annoyance! I have personally provided a setup with fixes for a bank deployment and was very happy to have the problem solved in my package
To debug yourself, you need to get hold of a tool to open cached MSI files on the system and you need to "hack" the database - a very involved task requiring expert skills, you would be advised to seek an installation expert for help if the problem is very serious for your desktop environment. It can work, but don't expect miracles.
Please see the section below called "Finding the trigger or culprit for the self-repair" for more details on obtaining a tool to view and modify MSI files
The rest of the "article" describes self-repair problems in depth. There are many other potential causes of self-repair than what is described in this "short" section.
Overall Problem: Developer debugging and self-repair
Windows Installer is a deployment technology, its job is to install the specified files and registry settings and keep them in the specified install locations and to ensure they are the right versions - self-repair or resiliency is a mechanism to that end. Its operation conflicts with a developers need to exchange files on the fly for debugging, development and testing.
Accordingly, many self-repairs (resiliency) are triggered simply by developers trying to debug their installed application and hot-swapping files on the fly. See section 2 in "Some typical self-repair problem scenarios" below for how to handle this. In other cases there are genuine design errors in the MSI that must be corrected or system administration pitfalls that lead into self-repair - and at times the error source can be hard to find.
I have written about the issue of self-repair in an answer on serverfault.com. Slightly different words intended for system administrators, and reading it now it might be a more accessible explanation than this long one (intended for developers). There is also another, shorter answer here on stackoverflow: Why does the MSI installer reconfigure if I delete a file? (this is probably the shortest one and easiest to understand). And finally I found a very nice article on self-repair by Vadim Rapp: How to fix Windows Installer Efforts to Self-Repair. This article is well worth a read.
No self-repair will occur if Windows Installer determines that the product being launched is properly installed. When self-repair occurs something needs to be changed on the system for the application to run properly.
The Primary Causes of Self-Repair
The details are presented below in the section "Some typical self-repair problem scenarios", but as a quick, foreshadowing list - the primary causes are:
1. Badly packaged corporate MSI files or MSI design flaws from the vendor (the MSI package itself is badly designed and triggers self-repair unexpectedly for a variety of reasons)
Excessive or erroneous use of per-user files or per-user registry keys often with erroneous key paths set into the user profile (instead of HKCU). See section 5 below for more details (and a color illustration of such a situation)
Package interference from erroneous COM server registration (particularly VB6 COM files or VBA files and libraries from products such as AutoCAD from Autodesk, and similar products).
Two MSI packages register the same COM file (ActiveX/OCX) from two different locations and "self-repair fight" on each application launch to keep their version correctly registered.
The last application to launch puts the registry right for itself, and it lasts until the other application is launched and does the same. Once you alternate between applications the problem occurs. See section 7 below for a lot more VB / COM self-repair detail
A component key path is set to an empty folder that Windows installer removes on self-repair (triggering an endless loop of removal and subsequent self-repair)
ACL lockdown permission problems (logged on user can not access key file and Windows Installer triggers repair repeatedly). This can also be caused by ACL changes done externally, but is often done by the MSI itself
Here is a serverfault.com work-in-progress describing common MSI design flaws
2. Files or registry keys are deleted by interference from external causes ranging from (logon) scripts to standard OS features, viruses, security software, etc...
Temporary files are deleted automatically by Windows after being erroneously installed to the temp folder by an MSI package
Interference from bad logon- and trigger happy cleanup scripts and cleanup applications
Antivirus applications blocking or deleting files or registry keys so that Windows Installer can no longer detect or access them
Computer viruses changing or deleting files and registry settings
Overactive computer tinkerers and users delete files and settings they don't understand
3. Windows design changes, flaws or restrictions that causes flawed or problematic deployment
An AD-advertised MSI package fails to install (might be cancelled since it takes too long to install) and keeps bugging people. This is strictly speaking not self-repair but an advertised install that is aborted, but the result is the same: endless reinstall
Terminal server complications. Self-repair is generally disabled altogether on terminal servers. This does not normally cause self-repair problems, but application installs without the required per-user files or registry keys that can be added via benign use of self-repair (read below). The user files and user registry keys are then just missing and problems result
UAC interference, certificate validation failure and other problems resulting from Windows design changes. For every version of Windows security features like these are added and normally end up adding new obstacles for reliable deployment
Even certain Windows Updates (updates, security updates, hotfixes, etc...) can make drastic changes to how security is enforced for MSI packages, and hence cause extremely problematic behavior
Though this relates to MSI creation, and not primarily their end-user use, the Windows Update KB3004394 which updates the way Windows checks for revoked root certificates, breaks older version of Installshield's command line build (for setups that were digitally signed). Largely a resolved issue by now, but an illustration of how Microsoft keeps changing core MSI functionality
In a similar manner Installshield crashed for many users after installing Microsoft update MS14-037 “Security update for Internet Explorer versions 6, 7, 8, 9, 10, and 11” (KB2962872)
An extremely problematic change in Windows Installer base functionality occurred after installing kb2918614 (Vista). Suddenly administrator credentials were required for a simple MSI repair operation. This defeated a core benefit of MSI altogether: the ability of regular users to run approved installs with temporary admin rights. There were also other reported MSI problems after installing that fix. It appears another Windows update fixed the issues: kb3008627 (later replaced by kb3072630)
About Self-Repair
Windows Installer is designed to install your application's binaries, settings- and data files and keep them installed and ensure they are the right versions. Self-repair is a mechanism to that end. The overall concept is called resiliency - i.e. a broken installation triggers a self-repair before the application is launched.
Resiliency, or self-repair, is a built-in primary concept of Windows Installer and can not be turned off in any way that is safe. People do the most incredible things sometimes, such as disabling the whole Windows Installer engine to stop their self-repair. This must obviously never be done. The cause of the repair must be identified, and the problem resolved rather than creating new ones, or hacking the system.
Every time you launch an advertised shortcut (essentially a special shortcut that points to a Windows Installer feature and not directly to a file), Windows Installer will verify the installation by checking the "component key paths" for your product. If a discrepancy is found, a repair is triggered to correct the incomplete installation. The "component key paths" are the "key files" specified for the components inside your MSI - there is one per component. Self-repair can also be initiated by someone instantiating a COM server (or attempting to), someone activating a file via its file extension or MIME registration, and a few other ways. Here is a comprehensive article from Symantec on the subject of "self-repair entry points": Initiating Self-Repair and Advertising Features with Entry Point.
If files are deleted, moved or simply overwritten (manually by a user or somehow automatically), self-repair may result (if the file or registry setting isn't set as a key path self-repair is not triggered).
Finding the trigger or culprit for the self-repair
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
Alternatively you can do: Start => Run... => eventvwr.exe for just the event viewer. If you don't see run in the start menu, press WINKEY + R.
Look in the "Application section" of the event log and you should find warnings from the event source "MsiInstaller" with IDs 1001 and 1004
In the sample screen shot above the product code is shown inside the red box
In order to determine what product the product code is for, you can look up the product name via the procedure explained here: How can I find the product GUID of an installed MSI setup?
If you actually want to go in deep and check the actual content of the MSI file, you must get hold of a tool capable of viewing a MSI file (such as Orca, Installshield, Advanced Installer or similar). You then open the package listed in the "LocalPackage" path listing as illustrated in the screen shot found in the answer linked to in the previous bullet point.
The actual modification of the system-cached MSI file and/or the registry to remove advertised entry points such as (advertised) shortcuts, COM registration, file associations, MIME associations or command verbs is a specialists job. It is very involved and not good practice, but it is the only "last resort" that I know about.
Finally it is possible for an application to explicitly call Windows Installer itself to trigger self-repair for shared components - for example a spell checker. I believe a few versions of Microsoft Access did this, and this behavior can not be changed or worked around as far as I know.
MSI-expert and MVP Stefan Krüger 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.
Some typical self-repair problem scenarios:
This is the "verbose explanation" of several self-repair problem scenarios already outlined in the overview above.
A component key path is set to an empty folder that Windows installer removes on self-repair (triggering an endless loop of removal and subsequent self-repair). This is solved by adding the folder to the CreateFolder table instead (Wix equivalent). In my experience this is the most common scenario for unwanted self-repair. Very common.
Many self-repair problems are actually caused by developers trying to debug their applications by replacing files on the fly, deleting files or renaming them. Or they may use cleanup registry scripts and / or batch scripts to unregister and register COM files, COM-Interop, GAC files, file associations, or other common developer debug and development tasks.
This hot-swapping can triggering self-repair when the application is launched via an advertised shortcut.
A top tip for developers struggling with self-repair during application debugging is to not launch the application from an advertised shortcut, but to launch the main EXE directly from Windows Explorer or from a manually created shortcut. This will bypass the most common "self-repair entry point" - the advertised shortcut. Self-repair may still result from broken COM data, advertised file associations and a few other special cases (read this Symantec article for entry point information).
Other applications or rather other MSI packages can break your installation and cause self-repair by interfering with registry data - typically COM settings, but also with other settings and files. These can be some of the hardest cases to solve, since the applications are basically fighting it out and the last one to run will update the registry each time. Typically both MSI files must be redesigned for the applications to operate on the same machine. Or, as is the order of the day, the whole application may be virtualized (for example: Microsoft App-V virtual packages) and run in its own sandbox which seems to be what is done more and more in companies these days. This error scenario is often seen with a suite of badly repackaged applications in a corporate environment. COM fragments from different packages overwrite the COM server's disk path from another package, and self-repair fighting ensues on each application launch via an advertised shortcut. The same file name with different file versions can also be registered from different file locations and share some registry settings that interfere. As far as I recall at least 7 variables or settings in the file system and registry must be in sync for a COM server to be properly instantiable. See section 7 below for a more specialized description of COM interference in the context of VB6 and VBA COM applications.
A component key path is pointing to a temporary file that has been deleted by the application or it will be deleted by the system eventually via some sort of cleanup mechanism (can also be a cleanup tool such as ccleaner). This is common for files in the temp folder itself. This is solved by not installing the temp file, or putting the file somewhere else and making it permanent. I have seen this error most often in the world of corporate application repackaging where a faulty cleanup of the captured image leads to the install of a temporary file that should not have been included in the package at all. Often they may be temporary files waiting for a reboot to be installed to their intended, perhaps protected location, and the reboot was never performed - a common application packaging error. To a lesser degree I have seen it in auto-generated packages coming out of automated build systems.
Permission problems: if a key file for a component is installed to a location that is not accessible for the user who invokes the application. Windows Installer might not "see" the installed file / key path, or be unable to add the file to the folder. These issues can be more exotic to debug, and may not happen that often. There are several variations on this issue:
An example of this is when you install a file to a %USERPROFILE% path and then forget to set a HKCU registry keypath, and instead set the keypath to point to the %USERPROFILE% folder/file. This generally yields an inaccessible hard coded key path that is user-specific: C:\Documents and settings\user1\Desktop. This path will not be found for another user logging on, and self-repair runs in circles. Here is a color illustration.
Another example is key paths set to folders that are not writeable for the System account. This may seem exotic but can result from the MSI's faulty modification of system ACL entries, or from a strange system administrator security setup, or any other non-standard ACL / Security Descriptor.
Another class of self-repair problems emerges in relation to terminal servers and Citrix. The whole windows installer service could be locked down so any self-repair invoked to add per user data could fail and consequently self-repair may fail or more likely not run at all. This is reason enough to not rely on self-repair as a way to add user data like some MSI files do, and such constructs must be replaced with application deployment of user files copied from per-machine locations or the less effective ActiveSetup feature from Microsoft that runs once per user.
VB6 applications and VBA applications, which are heavily COM based with massive potential for COM interference (COM settings overwriting each other and becoming inconsistent), have been known to trigger several mysterious self-repair problems, most of which have not been properly explained. This can also happen on launch of Visual Basic 6 (VB6) or Visual Studio (and many other applications). The common denominator is that some error in the current installation state triggered the self-repair, and you can track down the culprit product and component by following the steps outlined in the section above called "Finding the trigger or culprit for the self-repair". Be sure to report your findings here (I never use VB6 or VBA anymore - your detailed findings could help others with a long-standing annoyance).
Though I have never debugged such VB6 issues in great detail, it would seem that the problems result from applications that install common controls, VB6 COM files, templates and VBA files and libraries that conflict with existing files and registry settings and registrations on the box, or some per-user registry key or userprofile file may need to be added once per user (allow the self-repair to complete once and see if the problem goes away). In particular I have heard of these mysterious self-repair problems when launching AutoCAD (from Autodesk), Visual Basic 6, and several other products (often with VBA automation available in the tool).
Some applications even erroneously install bits and pieces from the VB6 runtime on their own causing these settings to be "ripped out" on uninstall of those applications. This can certainly cause self-repair to be triggered to fix the now (partially?) broken VB6 runtime. There are several variants of this problem, and the "catch all" solution is probably a complete uninstall and reinstall of the VB6 runtime. Here is a description of a very common "specific" problem involving a few COM registry keys. It nicely illustrates what happens in this scenario.
If you experience unexpected self-repair when launching VB6, AutoCAD, Visual Studio or other products, you can first try a workaround to prevent these unexpected self-repairs from happening in the first place (this doesn't solve the problem, but may bypass its symptoms): why does windows installer start up everytime i start up visual basic 6
See my comment to the question in this topic for one of the most typical VB6 style self-repairs: Why does my application triggers the Installer of another application? (ActiveX control registered twice from two different locations on disk).
In my opinion the "general fix" - that should always work - for VB-COM self-repair issues, is to get the vendor to update their project in question to use the latest official and properly installed and shared ActiveX control / OCX available, and not to rely on their own version installed redundantly and registered in the wrong location.
A special case of Windows Installer repair or self-repair that is worth mentioning for completeness, was the issue with Microsoft Office several years ago where a self-repair would be triggered, and you would be asked to insert the Microsoft Office installation media (in those days CD-ROMs or DVDs - today maybe thumb drives). As far as I recall this was related to an erroneous call to the built in Windows Installer standard action "ResolveSource" which unexpectedly (and unnecessarily) triggered the prompt for the installation media. A very common support call back in the day and mentioned here for completeness. It is important to note that this problem can still occur whenever MS Office is installed from any removable media (rather than the better option of a network share). This happens when MS Office detects that it needs to install further, optional (and usually shared) components of the product that were not installed originally. For example unusual spell-checkers, various templates or specific and rarely used tools. It is possible to install these components to "install on first use" (advertised features is the proper Windows Installer term).
There are many other possible scenarios. To mention a few:
a bad logon script may delete things on the system and trigger self-repair
an AD advertised package may fail to install and keep bugging people
two applications may start fighting for the same file associations
computer tinkerers and hackers can manually delete data that trigger self-repair
anti-virus can quarantine files and registry settings that trigger repair
a virus can change or delete things and trigger self-repair
a disk and registry cleanup tool such as ccleaner can delete files and trigger self-repair
and no doubt numerous other scenarios...
Benign uses for self-repair
Finally there are benign uses for self-repair that happen once and do not constitute errors. This is the legal and proper use of self-repair though it may be just as annoying as the design errors, and with user intervention they can pop up again and again:
Self-repair is sometimes used to add per-user data to HKCU and the user profile. This design mostly works, but gets worse for every version of Windows as new obstacles are put in place for deployment. For one thing self-repair typically does not work at all on terminal servers rendering the setup incomplete. Though it is besides the point for this discussion, it is better to have the application copy files to per-user locations. Another issue is UAC. Other problems show up with each new Windows version and even with some Windows Updates as described above (virtual folder redirects, certificate prompts, previously non-existing target path restrictions etc...).
When self-repair is needed to set up user data, it may take so long that the user aborts it and keeps doing so. This causes the self-repair to reappear all the time until it is allowed to finish. A common support call.
It is also possible to install a product with "advertised features" that are designed to be installed "on demand" triggered during application use. Few applications use this, but when it is used a lengthy "self-repair style" installer may run - pulling down the required files and settings. If this process is cancelled the installation of the feature is rolled back and it can be triggered again. This install can be slow for several reasons:
If the installer used large, compressed CAB files that are first downloaded and then extracted locally on a slow disk where the anti virus starts scanning the whole cab and then each extracted file the operation can take a long time.
The operation can also be slow if the network connection is wireless and there are lots of small files to download (high latency), and again the anti virus could slow down things.
If installed from removable media, you could get prompts to insert the source media to allow files to be copied. A very common support call if removable media is used in an office environment (it shouldn't be - use an admin install on a network share)
Etc...
I've developed a Wix installer for an internal project however entirely by accident I've found that I'm unable to uninstall the installer on my development machine as I get the following error message:
The feature you are trying to use is on a network resource that is unavailable
with a dialog pointing to the path of the .msi that I installed from feature from. (The .msi is there, however is has been rebuilt and so has changed since I installed it)
I'm concerned by this dialog as I had believed that Windows Installer kept track of installed .MSI files, however this dialog seems to suggest that I can break my uninstaller by deleting, moving or changing the installer.
Is this the case?
What do I need to do to make sure that I don't break my uninstaller in this way? (Do we need to keep copies of all versions of the installer ever installed on a machine?)
The easiest way to get out of this situation is to do a recache/reinstall. Build a new version of your MSI that isn't "broken" (in whatever way it is broken, in this case, it might not really be broken at all, you just need a new source). Then you use a command line like:
msiexec /fv path\to\your.msi /l*v i.txt
That will copy your.msi over the MSI that is cached and do a repair. Then you'll be in a better place.
One of the first painful lessons of writing installs is to never run your install on your own box. Certainly not until it reaches a point of maturity and has gone through several QA cycles. This is what we have integration labs and virtual machines for. (There is a saying about things you shouldn't do in your own back yard.)
That said, normally an MSI uninstall doesn't require the MSI but there are situations where it could be required. For example if one was to call the ResolveSource action during an uninstall, MSI would then look for the .MSI.
Now there are several ways out of this pickle:
Take an MSI you do have and edit it with ORCA to match to file name, UpgradeCode, ProductCode and PackageCode of the MSI that you installed. You should be able to get all of this information from looking at the stripped cached MSI that exists in %WINDIR%\Installer. CD to that directory and do a findstr -i -m SOMESTRING *.msi where SOMESTRING is something unique like your ProductName property. Once you know the name of the cached MSI, open it in Orca to get the required attributes. Then put these attributes in a copy of the MSI you have available and try to do an uninstall. No, it's not the exact MSI that you installed but usually it's close enough.
or
Use the front end windows installer cleanup utility (if you still have it) and/or the backend MSIZAP utility to wipe all knowledge of the application from MSI and Add/RemovePrograms. Note, this doesn't actually uninstall the program so you'll have to also write a script or otherwise manually uninstall all traces of the program.
or
Reimage your workstation
If you know exactly what is wrong (which is often the case during development), I prefer to open the MSI file that Windows will use for uninstallation and edit it directly with a tool like Orca to fix or remove the part that causes the failure.
For example:
Locate the MSI file in %WINDIR%\Installer. The MSI should be the last edited MSI file in that folder right after you did the failed uninstallation.
Open the msi file with Orca.
Remove the failing part - for example the InstallExecuteSequence action that fails which is atypical scenario.
Save the msi and close Orca to release the lock on the msi file.
1 - Have you experimented with "run from source" during installation?
This is an option in the feature tree which allows you to run some files from their installation source. This is generally combined with an admin image on the network. See image below. I haven't tried it, but I assume this could cause: "The feature you are trying to use is on a network resource that is unavailable" if the network is down and you are trying to uninstall. Just a theory, there are other ways this could happen.
2 - Are you running script custom actions? If so, do you extract to the tmp folder or run from installed files or the binary table? If so, is the custom action conditioned to run only on install?
3 - Are you perhaps running an EXE custom action that is pointing to an installed file? If so this file may be unreachable on the network.
4 - Are any of your userprofile folders redirected to a network share?
5 - Are you installing anything directly to a folder on the network?
There are plenty of other possibilities.
I've created a WiX setup project based on the article WiX 3 Tutorial: Understanding main WXS and WXI file mainly because it gives the WiX needed to do an application shutdown.
However, I'm puzzled by the outcome. Here's the situation:
We have an executable which uses a dll and create a setup which installs the executable and the dll. We execute the setup.
CASE 1: Next, we change the executable and NOT the dll and create the setup again. Then we start the installed application and make sure also the dll is loaded. If we now execute the second setup, a dialog is shown asking the user to shutdown the executable just as we expected.
CASE 2: But if we do not change the application but only the dll and then execute the setup while the application is running and the dll is loaded, no dialog is shown. At the end of the setup a dialog appears asking if we want to restart the computer.
Is this expected behaviour and how can I force the application shutdown dialog of CASE 1 also when only a dll is changed as in CASE 2? I do not want the user having to restart the computer because the application is running on a server which cannot be restarted.
This is all determined by Windows Installer during the costing process. The installer decides which files need to be installed / updated and calculates how much disk space is needed and if there are any file locks. If there are file locks, it attempts to resolve the lock to a process with a window handle. If it can do this, you'll get the dialog. If it can't, you won't. This doesn't mean a reboot won't be needed, it just can't give you useful information on how to avoid it.
A few additional points:
Make sure you are versioning your EXE and DLL. If the old DLL is 1.0.0.0 and the new DLL is 1.0.0.0 costing will say "Nothing to do here".
How does the EXE use the DLL at runtime? It might simply not have a lock on it during the entire life of the process.
Understand that MSI's reboot behavior can be altered through the use of properties such as REBOOT=ReallySuppress
Here's some good articles to read:
InstallValidate
FileInUseDialog
System Reboots
I haven't checked the code but I think what is happening is the CloseApplication action is not running because it sees that the exe hasn't changed. As far as I am aware you cannot target a DLL with CloseApplication. If you run your install with logging you should be able to see if the action is triggered. I am assuming you have RemoveExistingProducts schedule late in the install, if you were to move it after InstallValidate it would remove the exe every time and therefore trigger the action.