I have my application set up to only allow one install. If the application is already installed wix nicely pops up with this message
Is there a way to give the user the option to uninstall the application at this time? I don't want my users to then have to go to menu -> app -> uninstall or control panel. I would like to make it easy for them to remove the old version and install the new one.
That message is a feature of Windows Installer - it's just the way everything works, based on the fact that the product's ProductCode and PackageCode are present on the system. Since that message comes from Windows (not WiX) there is no tailoring it to install the MSI file that prompted it.
You can't have the same ProductCode installed more than once per-system install, so an option to install another MSI with the same ProductCode doesn't exist unless you make it a minor update by installing an updated version of the MSI file with an update command line.
The way you make it easy to upgrade is to use the WiX MajorUpgrade tag. You also need to increment ProductVersion in the first 3 fields, have a new ProductCode, keep the same UpgradeCode, and decide where you want the upgrade sequenced, and that depends on whether you increment file versions for updated files, and preserve component IDs for the same resources. This installs the new product while uninstalling the older one. This standard automatic major upgrade doesn't say "do you want to upgrade to this new product?". It just does it, the assumption being that people are in fact pretty smart and they are well aware that they have a new version of an installed product and that this will upgrade it. The upgrade is also a fresh install for people who don't have any old versions installed.
Related
I created a Wix Installer for my Visual Studio 2017 project by using this Wix Toolset Visual Studio 2017 Extension from its original author Rob Mensching. The installer successfully installed the app but when I run the installer again to uninstall the app, the installer, as expected, first shows the option of either repairing or uninstalling the app.
When I choose Uninstall option it successfully runs indicating it's uninstalling and finally shows the Finish button, but when I go to my Windows 10 menu the app is still there and still works as usual - that clearly means it was not uninstalled.
I even re-started the computer to see if that makes any difference but the app is still there and working as usual. Question: What could be a cause of it happening - and what is the remedy?
Note: I'm using the latest version 3.11 of Wix
UPDATE
It's a VSTO add-in. Now it is working as follows: I manually uninstalled it from Windows' Add\Remove program and then installed it again using Wix/MSI. And then when I uninstalled again using Wix/MSI it successfully uninstalled it. Question: Why initially it was not uninstalling when using Wix/MSI?
Duplicates: You have probably installed the product several times (at least two) whilst working on the package. This happens all the time, particularly if you use an automatically generated product code and haven't set up a major upgrade construct yet or the upgrade guid is missing or worse yet you set it to auto-generate. Upgrade codes should remain stable for "families" of products. Essentially all related editions that you don't want to install side-by-side.
So with duplicated installations, the uninstall of the product only removes the latest installation, leaving the files in place since the reference count is not zero as there are other installations. The solution is to keep a stable upgrade guid and set up a major upgrade construct. Before that uninstall all stray copies.
Maybe try this procedure:
Windows Key + tap R
Type appwiz.cpl and press Enter
Look for duplicate copies of the product in the list and uninstall them.
Hidden Products: It is also possible that some copies could be hidden from the above list.
Find Product Code: You can list all installed product codes and the product name using approaches described here: How can I find the product GUID of an installed MSI setup?
Uninstall: Once you have the product code you can uninstall via method 3 here: Uninstalling an MSI file from the command line without using msiexec
More Advanced: Here are some further options to uninstall via scripts: WIX (remove all previous versions).
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 am currently using WiX Toolset to build my installer. This tool is very nice but recently I encountered a problem. When I installed my program with .exe, then upgrade it with .msi, there is a double-entry in Add/Remove Program. Is there anyway to prevent the installer add double entry? Thanks!
It's not clear from your post if you have followed the rules for a major upgrade, such as use the same UpgradeCode, new ProductCode and PackageCode, increment ProductVersion in the first three fields, have upgrade logic in place in the MSI (such as major upgrade element). You'd need to supply your WiX source for these in the old and upgrade builds to see the differences. A verbose log would also help, installing the MSI with a command line that includes /l*vx [path to log file]
If those rules have been followed, the main reason for failure to upgrade is the one was per user and the other is per machine (or vice versa). One context will not upgrade the other. If this is the case the log will have an entry somewhere with FindRelatedProducts referring to an installed product in another context.
All this also assumes that the original install you did was MSI-based underneath the exe. If it was not, and it was some other install software that is not using an MSI file then there is no such thing as an automatic upgrade. You'd need to find some none-MSI way to uninstall the older product. A typical way is to find the UninstallString in the registry for that product and run it. Depending on the software used, that command can be parsed to add a silent option.
I have a custom installer based on WiX technology which is install several .vsix packages into Visual Studio.
If this packages are already installed, the installer offers to remove them. After the removal process is completed, the installer exits.
It's normal behaviour, but I need to offer the user re-install this packages (optionally) before exit. I mean optional mode to uninstall the previous version and install the new one (or the same) with a single run of the installer.
How to implement this in WiX ?
I suspect your custom installer could be made a little smarter. There are plenty of APIs (such as MsiQueryProductState) that will tell you if that exact ProductCode is installed, and ways to get the version (MsiGetProductInfo). My guess is that your custom installer is just firing off all the MSI installs without checking if they are already installed, hence the Remove prompts.
Your general plan should be to have some data available to your custom installer that it can use to find out what's already installed and what the versions are, and then compare these with what you are about to install. Use those APIs. If the product is already installed then skip the install. If you have a newer version (that you built with the WiX MajorUpgrade element) then just install it because it will replace the existing older one.
There's nothing I can think of in WiX that would automatically reinstall a product that your custom installer caused removal of by re-installing it and prompting the user to remove it, if that's what's going on.
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.