I've created an installer for a Windows Service using WiX. The installer installs and configures the service with no issues. It also uninstalls the service with no issues if it's not running. If the service is running, it may or may not stop and uninstall the service with no issues depending on how long it takes the service to stop.
What I'd like to do is check if the service is running on uninstall, and if so, display a message and then rollback the uninstall. I was looking at the WiX Toolset documentation but nothing jumped out at me.
Related
I have an MSI that was authored using WiX. It installs a VSTO office addin. With an office application running (and thus the addin loaded) instead of a FilesInUse dialog with retry, ignore, cancel I only get a retry and cancel. The installer log shows a 1306 then a 1603 error. In interactive mode InstallValidate says there's an exclusive lock on this file. The installer seems incapable of overwriting this file via delayed reboot.
I've set MSIRESTARTMANAGERCONTROL to Disable for testing purposes. Eventually this will be called by a burn exe but I'm trying to get my head around the root issues first. Currently burn displays the retry/cancel dialog and if I run it with /passive /norestart it just tries to install the MSI 4 times and then fails.
The interactive experience isn't too horrible (close the app dummy!) but the silent experience fails and doesn't do the force install /reboot that I normally see.
What important trivia am I not remembering?
Update: I set MSIRESTARTMANAGERCONTROL back to it's default and set MSIRMSHUTDOWN to 1 and this has fixed all the silent MSI installation scenarios. However when I have WiX Burn run it as an MsiPackage it fails. I think it's because Burn is passing MSIFASTINSTALL=7 which skips some of the costing steps. I tried adding MSIFASTINSTALL=0 but I see both getting passed to the MSI and the behavior doesn't change.
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).
I'm trying to certify a desktop application for Windows 8.1 using Windows App Certification Kit 3.1.
Everything is fine with the exception of the uninstall. I created the MSI file using Wix Toolkit 3.6. When the application installs it creates an entry in Programs and Features as well as a shortcut for uninstalling.
When I trigger the uninstall from either of these locations it works properly and all the files and registry entries get removed.
However, when the WACK launches the uninstall process, the MSI starts the installation process instead.
Is there a specific command from msiexec I need to test that WACK might be using to cause this?
I really do not understand why the Kit will launch the installer again.
Thank you,
Fernando
I found the problem and my solution.
The WACK calls the uninstall process using the Change option instead of Uninstall. You can test this by going to *Programs and Feature*s and clicking Change.
Since my application does not support changing or repairing, I simply set ARPNOREPAIR and ARPNOMODIFY to "Yes" and now WACK only calls uninstall.
The other option is to offer the Change/Repair dialog on your setup project and have the Remove check-mark available.
Hope this helps.
Cheers,
Fernando
We have an application that gets installed at a customer's location. This application consists of a self-hosted WCF server running as a Windows service, as well as a client application that isn't related to this problem.
We publish updates to our customers by having the service download our WiX-generated .msi file in the background, then it is installed when the customer chooses to install it. The installation procedure is as follows:
The server copies a bootstrapper application to a temporary path and runs it, passing it the path to the MSI file to install
The bootstrapper uses the upgrade code in the MSI file to uninstall the previous version, then install the new version. It invokes the installer using various P/Invoke calls related to MSI's, like MsiInstallProduct.
The bootstrapper restarts the service
The issue is that at almost call customer sites, this automated process fails, though as with everything, it works in both testing and production at our location. Sometimes it fails during uninstallation, but normally it's during installation. Error codes 1601 (InstallServiceFailure) and 1603 (InstallFailure) are as common as they are entirely unhelpful in determining what went wrong.
We have a backup procedure whereby the user can manually invoke the installer by running the bootstrapper from within Windows (Run As Administrator is required, of course). This process works without fail, and it uses exactly the same installation logic as the automated process that fails.
All services are running as accounts with, at minimum, administrative privileges on the server box.
Where can I start in either trying to find more information about what is causing the error(s) or, even better, prevent them in the first place?
EDIT Here's one example of a failed install's verbose log file:
=== Verbose logging started: 3/29/2013 8:23:30 Build type: SHIP UNICODE 5.00.7600.00 Calling process: <<PATH TO MSI>> ===
MSI (c) (00:7C) [08:23:30:194]: Resetting cached policy values
MSI (c) (00:7C) [08:23:30:262]: Machine policy value 'Debug' is 0
MSI (c) (00:7C) [08:23:30:418]: ******* RunEngine:
******* Product: <<PATH TO MSI>>
******* Action:
******* CommandLine: **********
MSI (c) (00:7C) [08:23:30:491]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (00:7C) [08:23:30:520]: Grabbed execution mutex.
MSI (c) (00:7C) [08:23:30:562]: Failed to connect to server. Error: 0x800703FA
MSI (c) (00:7C) [08:23:30:605]: Failed to connect to server.
MSI (c) (00:7C) [08:23:30:637]: MainEngineThread is returning 1601
=== Verbose logging stopped: 3/29/2013 8:23:30 ===
This is too broad of a question to answer but here's what I've designed for other customers:
1) The elevated service downloads the MSI to a local directory and "advertises" (blesses) the MSI using the command msiexec /jm foo.msi
2) The non-elevated client side component then installs the MSI using the command msiexec /I foo.msi
The MSI must be properly designed and UAC compliant. The transition from Install UI to Install Execute will happen without a UAC prompt. Only properly scheduled ( deferred without impersonation ) custom actions will run elevated.
Once all the kinds were ironed out, the customer was very happy with their autoupdate pattern.
Maybe you need to look into another corner:
When I came over strange installation problems in the past, they were usually caused by behavior analysis tools which exidentally blocked something they shouldn’t have. If some such a tool—may be part of a virus scanner suite or a standalone application such as ThreatFire—is installed on the computer in question, make sure no parts required for your update procedure are listed as “blocked” anywhere. If your update performs actions that lead to auto-treatment by the behavior analysis component, make sure to white-list them reliably.
I am using msiexec.exe to install an MSI with the /passive option, to discourage cancellation.
The problem is that if Windows Installer detects a system reboot is necessary, the reboot happens immediately after the installation finishes, and this interrupts the user's work.
I could use /norestart to avoid the interruption.
But, is there a way to enforce such a restart with a delay first? Something like /forcerestarteventually?
In an NSIS installer I just invoke the Windows shutdown.exe utility. I suppose using /norestart and SystemRebootPending in a custom action, is one possibility.
Are there any gotchas with that approach, or is there something much easier?
Developing the MSI with WIX, for XP / Win7 - fairly easy on Windows Installer version requirements.
There is no 'force-restart-eventually' option. However, the Restart Manager API can eliminate or reduce the number of system restarts that are required to complete an installation or update. Custom Windows installers can be designed to call the Restart Manager API to shut down and restart applications and services directly to avoid requiring a system restart. In cases where a system restart is unavoidable, installers can use the InitiateShutdown or ExitWindowsEx function to schedule it in such a way that it minimizes the disruption to the user. See the main Restart Manager documentation but also see the Using Windows Installer with Restart Manager section in the Windows installer documentation.