Let's say that I have distributed a WiX Burn package with a certain upgrade code (I do not know any product codes). Let's say that I decide that moving forward, I want to move to an MSI package. The question is: how can I remove the previous Burn package given the upgrade code when I install the MSI package? I have given both the same Upgrade Code, but the MSI appears not to uninstall Burn by default.
You'd likely need to write a custom action in your MSI that walked through all registry keys under:
HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
and searched for a registry value "BundleUpgradeCode" with the value of your static UpgradeCode guid. When you find it, read in the value of the entry "UninstallString" or "QuietUninstallString". That's the command you'll need to execute in order to uninstall the previous bundle before installing your new MSI.
Caveat: there's no rollback support with this approach if you uninstall the old bundle and the new MSI installer fails. You'll end up with a machine that has neither of your products installed.
Related
I have a WIX Bootstrapper Burn bundle which contains 4 MsiPackages and has been released in production. Our latest version of the bundle is to no longer ship one of the packages and should uninstall the package should it exist. What is the best way to uninstall the MsiPackage without providing the entire msi in the bundle?
I have tried:
Removing the PackageGroup from the chain entirely - This leaves the product behind.
Adding the MsiPackage and setting the installlevel to 0 - This needs a very large payload as the msi that is being removed is large.
I also tried using product search to find the state
<util:ProductSearch Id="AppX" UpgradeCode="XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX" Result="state" Variable="APPXSTATE" />
but tried to hook it up to an ExePackage to run msiexec /x UpgradeCode but I figure is the wrong way to uninstall.
Whats the best way for me to purge msi with UpgradeCode X if it exists in this newer burn installer?
Thanks
Note: I am not aware of any auto-magic constructs to use in collaboration with util:ProductSearch to uninstall existing MSI
installations.
Upgrade Table: I assume the four different products have different upgrade codes "per family"? If so - and if you are positive it will never need to be installed again - then I suppose you could specify that it should be uninstalled via a major upgrade for one or more of the packages you will keep delivering. Note: It might be possible to uninstall even if all setups share the same upgrade code, but that requires a lot more care and testing.
This solution involves adding the upgrade code for the MSI you want to remove to the upgrade table of those MSI setups you want to preserve with a version range specified that will uninstall all "known prior editions". Technical details for how to do this can be found here: Adding entries to MSI UpgradeTable to remove related products. As stated it is enough to do so for one of the products that will remain, but you can do it for all of them to be sure. No errors should result if the product has already been uninstalled. I might want to set a tighter range than what is shown in that technical sample for the versions targeted.
ExePackage: It should be possible to uninstall as you have suggested by using an ExePackage instead. It could run msiexec.exe directly I suppose, or maybe launch a VBScript, Powershell script or even a batch file or your own EXE file compiled from C++ or C# (the latter with unfortunate runtime requirements). I have never tried this approach.
Please note that you do not uninstall by upgrade code in the fashion you do with msiexec.exe /x UpgradeCode - at least I have never been able to make that work (not tested for a while). Instead you need to uninstall via product code (How can I find the product GUID of an installed MSI setup?), OR you can use VBScript and MSI API automation to uninstall by using the Installer.RelatedProducts function and then kicking off uninstall that way as shown here: Powershell: Uninstall application by UpgradeCode. This is similar to what happens when Windows Installer processes the Upgrade Table. All releated products - those sharing the same upgrade code - are enumerated and you can handle them as you do so.
Some Links:
Powershell: Uninstall application by UpgradeCode
WIX (remove all previous versions)
Wix upgrade goes into maintenance mode and never does upgrade
I'm using WIX to create a new installer for an existing product. The installer is very simple - just drops a few dll's into a specified folder on disk.
In the field, my users already have that folder with old dll's in them (since they installed the old MSI - created using a *.vdproj project in VS).
My problem is that after I install the WIX, I have both the old MSI and the new Wix MSI appear in Add/Remove. Expected (? since these 2 are two different kind of MSI's?). I need some kind of an upgrade mechanism - so I was wondering if I can call the old MSI uninstaller from within the WIX one. Or alternately somehow take care of the old Add/Remove entry (a registry hack perhaps?)
Assuming the old install and the new install are installed using the same context ( per-user -> per-user or per-machine -> per-machine ) you can use a MajorUpgrade rule to find the old version and get rid of it. You can do this by syncing up the UpgradeCode property and using a higher ProductVersion or you can do it by authoring a second Upgrade rule using the legacy UpgradeCode GUID.
If the old install was per-user and you want the new install to be per-machine you are out of luck. This isn't supported by MSI. Typically I only support per-machine installs and hardcode the ALLUSERS property and remove the CustomerInformation dialog from the installer UI experience. This is not the default experience for VDPROJ based installers.
I have created a Wix custom bootstrapper application and bundle file using Wix 3.8. Bundle file contains five MSI packages. Created a setup and installed it. All MSI packages are installed and uninstalled correctly.
Then, I have include "InstallCondition" attribute in each MSI package elements in bundle file. Installed the setup based on the selection (installed three MSI packages). Installation working fine.
Now I want to uninstall any of selected MSI packages from installed packages (three packages installed) using custom BA.
Is it possible do the above using Wix CBA? Please share any idea regarding this.
Thanks
You need to call Plan with the Modify action (or Uninstall if you want to uninstall the whole bundle). Then in the OnPlanPackageBegin callback, set the desired state of the package (Absent to uninstall). I think if the InstallCondition of a package evaluates to false during a Modify or Uninstall action, the engine would plan to uninstall it by default.
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.
I have a Wix project that I have set to allow major upgrades. I'm using WixUI_Advanced for a choice between per-user and per-machine installs. When I install and upgrade per-user everything works as expected, the installer recognizes an upgrade and there is only one entry in Programs and Features. However when I choose a per-machine install, it starts duplicating entries in Programs and Features (even when both install and upgrade are per-machine and to the same folder).
Looking at the install log file it seems that FindRelatedProducts is executing before the user gets a chance to select a per-machine install, so the installer thinks that the context has changed and won't do an upgrade. I attempted to suppress FindRelatedProducts in InstallUISequence but when I do that the installer still skips FindRelatedProducts in the InstallExecuteSequence.
What are my options at this point?
You could manually execute the FindRelatedProducts action again, after the installation context was selected. Use the MsiDoAction method. I used this approach once and it seemed to work.
A better approach would be to run your own custom action before FindRelatedProducts that would search for a previous version of the product already installed. That custom action should set ALLUSERS to either 1 or to Nothing depending on the scope of that previous version, so that FindRelatedProducts finds it and schedules its upgrade. A good idea would then be to disallow selecting the per-user scope for the user if the previous version was installed per-machine - otherwise the installer may have insufficient privileges to upgrade the previous per-machine installation.
This seems to be the approach taken by InstallShield. If you create an empty test MSI package with the free InstallShield Limited Edition and then de-compile it with Dark, you will see that that custom action is called IsSetAllUsers and located in SetAllUsers.dll.