I have a WiX installer project which installs a client app and a windows service. It is set to stop the service during install. However it still shows the error window "The following applications are using files which the installer must update" with the "Try Again", "Continue" and "Cancel" options. If I choose continue and inspect the windows event logs for the installer it shows the service being stopped and started again. The StopServices element is in the recommended sequence position.
How can I avoid the error window?
[Edit] My understanding is that it doesn't matter what order the files are listed as windows installer stops the service before copying any of them. I had wondered whether the service exe needed to be listed first.
Best solution: Use the "ServiceInstall" and "ServiceControl" elements to ensure the service is stopped/started (and installed/uninstalled) correctly.
In fact in our installer the app and service were being stopped/started from within custom installer code. However the check for whether the files are in use occurs before the custom installer code is run. So the files are in use when the installer starts, but are not in use by the time the installer attempts to copy the files. So annoying to the user, but not actually an issue. And if installed using msiexec.exe in quiet mode then the install succeeds.
Furthermore we had another issue with the service returned from the shutdown call, prior to actually having shutdown. (As commented by #PhilDW).
Related
I'm working on an MSI installer written in Wix. The installer works in both per-user, and per-machine contexts.
In a per-machine installation, everything goes smoothly; the product is installed and configured for the initial user. Upon switching to a test user, the application appears in the start menu correctly. Running it for the first time, a msiexec process starts with the message that the app is being configured. However, if the original .msi has been deleted, this process fails.
The failing setup action gives the following message in its log:
Error 1706. An installation package for the product myProduct cannot be found. Try the installation again using a valid copy of the installation package 'myInstaller.msi'.
=== Logging stopped: 3/16/2017 11:15:52 ===
I understand from reading a blog post by Rob Mensching (Lead of Wix) that it probably isn't possible to just edit the source list to point towards the windows cached .msi, a point backed up by another article I've found. Is that correct?
Is there a way to stop this entire action of calling the msi on first run by users from happening? Caching the msi or keeping the original is not ideal, I'd like to use the .msi in a custom bootstrapper that involves deleting the msi once installation is complete.
Microsoft recommends you keep the original MSI available, Rule 31:
https://blogs.msdn.microsoft.com/windows_installer_team/2006/05/24/tao-of-the-windows-installer-part-3/
and I won't repeat what it says about repair/resiliency, but you cannot guarantee the source MSI won't be needed sometime.
You're probably getting this "repair" because there is some resource (a file most likely) that is being installed to a user-profile location. When another user logs on and uses the application that file is missing, so potentially the application is broken. For example a file installed to User's Application Data needs to be available for all users of the system, not just the user that installed it.
So keeping the MSI might not be ideal but is strongly recommended, and in your case of product use by multiple users it's even more likely to required. There should be an Application Event log entry under MsiInstaller that says something about the missing resource.
In an msi, we use the following to get explorer to restart so that it loads our shell extension.
<util:RestartResource Path="[WindowsFolder]explorer.exe"/>
However, now that I've wrapped this msi up with its dependencies in an installer created with burn, the restart of Explorer no longer occurs.
How can I get the restart to still occur?
Thanks.
The msi normally displays some UI asking the user to reboot. This UI is hidden when wrapped in a burn/bundle exe. I thought perhaps the burn engine would issue callbacks allowing a custom bootstrapper to display the relevant UI. I tried overridding OnExecuteMsiMessage in a custom bootstrapper application, but don't see any message that would appear to give me an opportunity to display the UI that's required for the Explorer.exe restart.
When closing my application it prompts users to save any unsaved information. When installing a new version of my application while it is running the following occurs:
Start application.
Install new version from WIX MSI.
Application prompts to save unsaved information.
WIX MSI ignores the fact the application is not closed and continues uninstalling the old version and installing the new version.
The still running application crashes badly.
How can I get WIX to abandon the installation if the application does not close?
As per my understanding, you want to stop the installation and inform customer to close the application if your application is running.
You can do this using custom action. Check your application is running or not using Process and create a property based on that in custom action.
Schedule the custom action after AppSearch or before Launch Condition in both InstallUI and InstallExecute (for silent installation) sequences. Check that property using condition element.
<Condition Message="Please close XXXX application to continue the installation." >APPLICATION_RUNNING</Condition>
When installing an MSI package, any shared files which get upgraded will automatically force the other components/services that use that file to restart. This is done using the Restart Manager on Windows Vista and above.
In my situation, one of the files being upgraded is a file that belongs to the service which is actually running the install. This service takes control of when to reboot the machine itself, but because it gets restarted, it doesn't get the return code from the MSI process that says it needs a reboot. Hence the machine doesn't reboot, leaving the system in a broken state.
I need some way to prevent this control service being restarted, and instead allow it to reboot the whole system instead. Windows Installer can schedule files to be copied on the next reboot, but how do I force this behaviour in the case of these shared files?
Use the various restart manager MSI properties to prevent the Restart Manager from kicking in (specifically MSIRESTARTMANAGERCONTROL=DisableShutdown)
Add a ScheduleReboot action to prompt the user to reboot on completion of installation
You can force a system restart by scheduling a ForceRoboot action. You can condition the execution of this action to suit your needs.
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.