I am using WIX bootstrapper for installing the newer version of the Installed MSI. The issue is during the installation if one of my files in the MSI is being used by any of the processes, I want them to be queued for installation and prompt a message box telling the user to reboot the system so that the queued packages will be updated after rebooting.
Related
I have an MSI and an EXE generated with Burn that warps the MSI. Although I can get the exe to properly run a minor upgrade every day I have a new build, when automatically run on DoD hardened systems (In this one case McAfee Endpoint Security with Access Protection, Exploit Protection and ON-Access Scan all enabled) the burn generated EXE fails with a Failed to launch clear room process error. So I went down the path of manually executing the MSI. Now I can get this to update the binaries are restart my service, however the version in the Add/Remove programs is not updated. Is there anyway to get the version number to update in add/remove programs without Burn and without uninstalling first?
I am using the following command line to run the MSI:
msiexec /I "[myinstaller.msi]" REINSTALL=ALL REINSTALLMODE=vomus -norestart
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'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.
I'm trying to uninstall an older version of our product which was installed using a WiX-built installer and after uninstalling it silently:
msiexec /x{GUID}
the program still appears in Control Panel. I've opened a separate item to
explore that mystery, but another curious issue has popped up. I noticed that after running the install for this program, two entries (GUIDs) are added to HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall. One with the product GUID and one that I have no idea where it comes from. I've searched through the .msi and it's not in there. Both are created each time I install, both are removed if I uninstall from the Control Panel and both are left in the registry if I uninstall from the command line. So have a look
Anyone have any ideas what's going on here?
Embedded Setup.exe: In essence it looks like you are installing an MSI that also installs an embedded non-MSI setup.exe via a custom action as part of its own installation sequence. Or, there is a setup.exe launcher that kicks off the MSI and the legacy setup in sequence. Result: two entries in Add / Remove Programs.
Uninstall: It is obvious, but to get rid of the second entry you must run its uninstall sequence - in addition to the uninstall of the MSI. Non-MSI setups are less reliable when it comes to uninstall than MSI packages. The implicitly available uninstall for all MSI packages with reliable silent running is one of the core benefits of MSI: MSI Core Benefits (among other topics).
Uninstall Commands: Try running the silent uninstall string, I guess that is what you have done?
Run commands elevated! With admin rights!
REM Uninstall MSI
msiexec.exe /x {PRODUCT-GUID} /L*v C:\MySetup.log /QN
REM Uninstall legacy setup.exe
"%SystemDrive%\ProgramData\Package Cache\{c5f0cb3e-1de3-4971-843a-abb981ed670c}\MDRSetup.exe" /uninstall /quiet
Silent Running: To run legacy setups silently you sometimes have to record a "response file" to record all settings in the GUI and pass to the uninstall process. I have some previous answers on this. You also need to run with admin rights:
Create MSI from extracted setup files
Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file
How to run an installation in /silent mode with adjusted settings
Application Repackaging: What is the name of the software you are installing? MDRSetup.exe, is that Max Data Recovery 1.9? Probably not. Getting rid of legacy software can be challenging. You can always try to re-package it as an MSI if you have the tools to do so, or maybe you have a team in your company to do so (all large companies tend to). Not all legacy setups can be repackaged. There could be constructs that are impossible to capture, such as certain drivers, generated and unique keys per machine etc...
Links:
Create MSI from extracted setup files
How can I use powershell to run through an installer?
Wix - How to run/install application without UI
Capturing all changes during an application install on Windows
I have created a Wix Burn app that I am installing two MSI's with. Works great.
The MSI files install properly
The Wix Burn app registers with ARP.
The MSI files do not register with ARP
I can do Major Upgrades
I can install and uninstall manually with a local copy of the Wix Burn app
I can programmatically execute the Wix Burn app to uninstall (using /x)
The Problem:
I know two way to uninstall using a Wix Burn app:
Click on the Uninstall button in ARP (requires user involvement)
Launch a copy of the Wix Burn app that installed the product
I see in the Wix Burn log that Windows caches my Wix Burn app install in much the same way that MSIEXEC will cache MSI files. Is there a way to programmatically ask Windows or MSI to use the cached version of the Wix Burn app to do the uninstall?
A Possibility:
Presumably I could use MsiGetProductInfo() to get a path to the cached Wix Burn app. To do that, however, I need my app's Product Code. However, Product Codes are not attributes of elements in Wix so I am not seeing how to get a Product Code for a Burn package.
You might be able to solve this by iterating through the Uninstall registry entries. The process is:
Open HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.
Iterate through the sub-keys searching for an entry where the Publisher and DisplayName matches your product.
If you find an entry, read the value of QuietUninstallString and run that as a command. For a WIX burn installer this is typically in the form C:\ProgramData\Package Cache\{GUID}\SetupProgram.exe /uninstall /quiet.
If you are using a 64 bit operating system you will also need to search HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall.