I implemented the MajorUpgrade element,
when I want to run the upgrade via the command line,
I have to to run the msi of the higher version with /i .(e.g msiexec /i <path_to_higher_msi>)
/u does nothing. (e.g does show no error/ no message at the event viewer and not install/upgrade)
How can I have it work?
For example:
I build the project with version 1.2.3 and install it.
Then I rebuild the same solution but with higher version 2.4.5.
and run msiexec /u
I can see in the Control Panel that the version was updated.
The bug starts as I produces two releases from the pipeline..
I have the same upgradeCode in both and a unique productId
Tnx.
Ok,
So I found the answer thanks to wix-user-list
There is no /u for upgrading,
/u is used for a patch in the current version, not for updating for an higher version
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'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 an msi that is not installed by my bootstrapper that needs to be uninstalled when the bootstrapper is being uninstalled(not when it is being installed). Is there a way to do this in burn?
Not today, there's an open feature request for bundles to be able to uninstall arbitrary MSI's by ProductCode - https://github.com/wixtoolset/issues/issues/4858.
Use a custom action and set its ExeCommand attribute to the msiexec uninstall command with the /x parameter. You will need to know the product code of that MSI.
msiexec /x {Package | ProductCode}
You can read more about msiexec command and its parameters over here.
EDIT: To prevent it from running during installation set the condition of the custom action to Remove="ALL". Read more about it here.
We normally install Wix patches (xxx.msp) by double-clicking them. But I see at various places over the internet that we should use the MsiExec utility. For e.g. msiexec /update patch.msp REINSTALL=ALL
Is there any downside in not using the MsiExec utility?
No, there's no downside. Effectively, double-clicking runs msiexec /p patch.msp.
If your patch updates only the versioned files, EXE and DLL, and work correctly without adding REINSTALL=ALL, then it's great!
The point of using msiexec explicitly is to add REINSTALL=ALL property. It make the installer to re-install all the files. This is usually added to fix the problems where some files do not get updated when the patch is installed directly by double-clicking.
I have created a wix installer project which is working fine. It installs my application on system easily. whenever if there is any change in any file or service, i uninstall msi from controk panel and installs new msi on system.
But whenever i install new msi, application's all setting change after new installation, that doesn't sound good. For sort out this, i am using Upgrade code in Product.wxs file. But when i install new msi after build, but is shows given error:
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel
So, i want to update windows application package whenever there is any change in files and with same Product id. I just want to update installed msi, dont want to remove that.
You cannot use the same ProductId to do upgrades, you need to change it. The best way is to set ProductId="*" and this will change it for every build. You will also need to increase the version number and this best done by using the main exe assembly version number. See http://wix.sourceforge.net/manual-wix3/major_upgrade.htm for more info.
You can use the same ProductCode to update an installed MSI. Basically you increment the ProductVersion, rebuild the MSI (with new PackageCode) and do a minor update with a command line such as:
msiexec /i <path to new msi> REINSTALL=ALL REINSTALLMODE=vomus.
In my experience this not commonly used because if you're going to rebuild the MSI you may as well upgrade with a major upgrade.
If all you want are updates to a few files and you're not ready to ship a complete MSI file, then that's what patches are for. Rebuild the MSI as above, then build a patch - the patch is the delta between the two MSI files, see docs for MsiMsp.exe.