I have lost the GUID's for my old installer. I managed to get the upgrade id using Orca but it still does not remove the old version from the programs and features list. How can I uninstall an old msi/bootstrapper with a completely new one?
If you have a MSI to uninstall (i.e. not a bootstrapper) then you should be able to uninstall it with WIX <Upgrade> element, by specifying it there like that:
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is installed." />
<Upgrade Id="{YOUR-OTHER-STUFF-GUID-HERE}">
<UpgradeVersion OnlyDetect="no" Property="OTHER_STUFF_FOUND" Minimum="0.0.0" />
</Upgrade>
If you have some EXE to uninstall, not MSI, then AFAIK only a custom action is a solution (just execute the uninstall line using custom action).
-Make use of the windows installer API: MsiEnumRelatedProducts() to get a list of all the products that share the same UpgradeCode.
https://msdn.microsoft.com/en-us/library/aa370103(v=vs.85).aspx
This API returns the product code of all the products installed on the system that share the same UpgradeCode.
You can probably see examples of the usage of this over the internet or Windows installer SDK.
Also, there was one related question recently:
WiX - Allowing a *manual* uninstall of one msi to uninstall another msi that shares the same UpgradeCode (and not just during the MajorUpgrade)
-The other approach is to upgrade your old msi package using the new msi package.
http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html
Another way would be reading Uninstall key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) from registry and look for your application name / publisher and if match found execute the UninstallString command.
Related
This problem, in fact, is to avoid a problem I will not solve
When I install my product once and I use the MSI again, the unloading process is performed.
However, this does not remove residual information from the registry, which must be cleaned Up using "Windows Installer Clean Up", and when reinstalled, a registry permission issue occurs.
I saw the Checking for Oldies, However, it was found that FindRelatedProducts only performed on the first installation, that is, when I installed the MSI again, FindRelatedProducts did not.
<Upgrade Id='YOURGUID-7349-453F-94F6-BCB5110BA4FD'>
<UpgradeVersion OnlyDetect='yes' Property='SELFFOUND'
Minimum='1.0.1' IncludeMinimum='yes'
Maximum='1.0.1' IncludeMaximum='yes' />
<UpgradeVersion OnlyDetect='yes' Property='NEWERFOUND'
Minimum='1.0.1' IncludeMinimum='no' />
</Upgrade>
<CustomAction Id='AlreadyUpdated' Error='Foobar 1.0 has already been updated to 1.0.1 or newer.' />
<InstallExecuteSequence>
<Custom Action='AlreadyUpdated' After='FindRelatedProducts'>SELFFOUND</Custom>
<Custom Action='NoDowngrade' After='FindRelatedProducts'>NEWERFOUND</Custom>
</InstallExecuteSequence>
So I'd like to ask you guys
How do I check every time I run MSI when I have installed it? Is it installed and the same version, If the same version has been installed, exit the installation process.
When you run the "same" MSI again it goes into maintenance mode, often just a repair. Windows doesn't even need to use the MSI you use for this "install" because it uses the original MSI for the install, which may or may not be the one you attempt to install again. So it's not clear what you mean by "the unloading process" or what you expect running the same MSI to actually do.
FindRelatedProducts is for major upgrades, but that means incrementing the ProductVersion and changing the ProductCode. Running the same MSI does not cause a major upgrade (see WiX MajorUpgrade element).
So again, what are you expecting to happen when you run that same MSI again? It seems that you are not uninstalling it, so it will go into maintenance mode using the original MSI file, so there is nothing you can do to change that behavior because it's embedded in the installed product's MSI. Since you are apparently not uninstalling the installed product, it won't remove its registry entries. You should say what those residual registry entries are and why they are residual if in fact the product is not being uninstalled.
MSI Zapping: I am not sure what exactly you have done - you seem to have zapped your installed MSI - which is not recommended at all. It can cause serious problems - up to and including total MSI database corruption in the registry.
However, first things first:
MajorUpgrade Element: You can use the more convenient MajorUpgrade Element instead of the older-style elements you are using. Here are the older-Style Upgrade Elements in use. Directly below is a sample of the more modern, MajorUpgrade convenience element in action:
<MajorUpgrade Schedule="afterInstallInitialize"
DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit."
AllowDowngrades="no" AllowSameVersionUpgrades="no" />
Maybe try this element instead of those you are using. Just comment the old ones out and replace with this simple element. If you do this correctly your major upgrade should work "out of the box". Make sure you specify an UpgradeCode in the Product Element. See the documentation for major upgrades
Relevant Links:
How to implement WiX installer upgrade?
Upgrading a WiX generated package with major version zero
How to implement WiX installer upgrade?
I did not fully understand this section of your question: "When I install my product once and I use the MSI again, the unloading process is performed. However, this does not remove residual information from the registry, which must be cleaned Up using "Windows Installer Clean Up", and when reinstalled, a registry permission issue occurs".
Zapping: What exactly did you do? Zap the installation? Why? You should be able to successfully uninstall from Add / Remove programs? Did that uninstall fail? What is the error message on reinstall?
Modify / Repair: MSI will detect when it is already installed in the same version auto-magically. You will then see the setup's modify / repair dialog show up, and not the first time installation dialogs.
These modify dialogs only show up if you double click the original MSI files used to install, without rebuilding it. Or you invoke modify from Add / Remove Programs.
If you rebuild your setup, it will have a new package GUID at the very least, and MSI will then detect that the freshly built MSI is not the one that is already installed, and an error message shows up. Now you can uninstall the current version from Add / Remove programs.
Related Products: An MSI will also detect if there are related versions installed if you correctly author the Upgrade table - as you seem to do.
If you generate a new product GUID each time you compile, you will be able to install the new version "on top of" or "side-by-side" with the older installation, unless you author the upgrade table - in which case the older version should be automatically uninstalled as part of the new version's install.
You need to understand package code, product code and upgrade code. The package code is auto-generated for every compile and build. The product code you can set to auto-generate by setting it to * in the product element, or you can hard code it and change it as required. The upgrade code should stay the same once defined. Please google the difference between these different codes - I don't have time to wrap up this explanation right now.
Developer created 3 installers of the same product and changed the UpgradeCode (yes, I know, but it is).
These installers were provided to customers and some of them used these versions.
Now I have built the new installer, then added records to the msi using SuperOrca: to uninstall the old product installations with incorrect upgrade codes.
How I can do it in WiX installer project do not using SuperOrca to patch the msi every time after it is built?
Upgrade code should not change. In an installer if you are releasing another major version you can change the product code but the Upgrade code should be same of a product throughout the lifetime. Add below tags inside product tag in Wix to automatically uninstall the previous version when you install the new version-
<Product Id="*" UpgradeCode="PUT-GUID-HERE" ... >
<Upgrade Id="PUT-GUID-HERE">
<UpgradeVersion OnlyDetect="no" Property="PREVIOUSFOUND"
Minimum="1.0.0.0" IncludeMinimum="yes"
Maximum="99.0.0.0" IncludeMaximum="no" />
</Upgrade>
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>
As OnlyDetect is set to No the wix will automatically uninstall the previous version after the InstallInitialize phase. Wix will detect the version from the range that you have mentioned as example given above-Minimum-1.0 to maximum-99.0
Many people seem to be under the impression that an upgrade can only upgrade one install and that there's something wrong with changing upgrade codes, but none of this is required. The Upgrade table in an MSI file can upgrade as many installed products as you like, as you know from using SuperOrca.
So all you need to do is add Upgrade elements naming the UpgradeCode values and range of versions you need. If there are three products that might be installed then add the three Upgrade elements naming them all. You'll end up with an Upgrade table (look in the MSI) that will turn out the same as if you added them with Orca.
I've created a WiX Installer with Product Version as 1.0.0
<Product Id="*" Name="My Application" Language="1033" Version="1.0.0" Manufacturer="My Client" UpgradeCode="182bbc7d-8cc2-4014-9e1c-29312598bxc0">
I'm using MajorUpgrade Element for Upgrading Installer as follows:
<MajorUpgrade Schedule="afterInstallInitialize" DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
Scenarios:
Scenario 1: Installing version 1.0.0 on already installed version 1.0.0
On installing the same version, the installer asks to either Repair or Remove, which is what I want and working fine.
Scenario 2: Installing version 1.0.0 on already installed version 1.0.1
On installing the older version, the installer throws error, A newer version of My Application is already installed and exits on clicking OK.
I want my Installer to display this error and continue installation by removing version 1.0.1 and installing 1.0.0
Scenario 3: Installing version 1.0.1on already installed version 1.0.0
On installing the higher version, the installer doesn't ask any thing and continues the installation by removing 1.0.0 and installing 1.0.1
I want my installer to ask for confirmation that whether to upgrade to higher version or to cancel the Installation
How can this be implemented?
To allow downgrades you need to set the property "AllowDowngrades" in the MajorUpgrade element. Go through all the attributes in the MajorUpgrade element from the below link.
WiX MajorUpgrade
The default behavior of upgrades is that they just happen. I think the assumption is that most people know what they are doing when they install an upgrade (or downgrade) and keeping intervention to a minimum is a good thing, and also in a silent upgrade install there is no way to ask for confirmation anyway - it just happens.
So in addition to allowing downgrades you'll need to add a confirmation dialog based on the property WIX_UPGRADE_DETECTED, maybe add an upgrade dialog that is shown conditioned on that property. That's a little awkward because all you know is the ProductCode of what you're upgrading (that's the value of WIX_UPGRADE_DETECTED) and no other information about the version that's already installed. So all you can say is that you are upgrading (or maybe even downgrading) the installed version. To get the information about the already installed product you'd need to query the system for the name and version of that ProductCode using something like the Win32 MsiGetProductInfo() API. That might require privilege (the UI sequence does not run elevated even if you are admin) so things get tricky pretty fast.
This is a fairly common question, so it's possible that someone has already done something, but a quick search didn't find anything.
I have a WiX installer for which I don't want to allow upgrades. Instead, I want the user to get a message saying that an existing version is already installed that they should uninstall that first.
I've looked at the WiX documentation, but can't see how to achieve this.
I had to add Disallow="yes" to the MajorUpgrade element:
<MajorUpgrade Disallow="yes" DisallowUpgradeErrorMessage="Cannot upgrade - uninstall existing installation first" />
I have my installer coded in WiX language. It supports major upgrade mechanism. A particular requirement is that the same MSI file will not be possible to install twice.
Now comes the tricky part: if user install and then try to install it again (UI mode) the installer enters in maintenance mode and everything works OK (Change/Repair will appear disabled.)
However when installing as our use case states in silent mode
msiexec.exe /i installer.msi /qn
The second install will proceed to install as normal (we don't want this!)
Some things to noticed about are:
In the log file of the second installation the sequence "FindRelatedProducts" will be skipped (as state in microsoft documentation http://msdn.microsoft.com/en-us/library/windows/desktop/aa368600(v=vs.85).aspx)
Also I research a bit an here http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/UpgradeVersion-is-not-detecting-the-same-version-preventing-downgrades-td5875840.html there is good information, claiming that for this scenarios we can used Installed property to detect if Product is already installed...
However, I get stuck here: because I have to avoid installing previous or same versions than current one and allowing upgrades greater, How could I achieve this in WiX?
Thanks for your help!
First all, you shall fix your upgrade code:
<?define ProductVersion = "0.0.2.3"?>
<?define UpgradeCode = "PUT-GUID-HERE"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Name="Asd" Language="1033" Version="$(var.ProductVersion)" Manufacturer="Me" Id="*" UpgradeCode="$(var.UpgradeCode)">
Note that the product code is recreated each time you build the installation (by not using the GUID but the asterisk).
The fundamental information is the product version and the upgrade code. The product code identify the specific deployed release, while the upgrade code identity the product releases "family". Softwares having the same upgrade code can be switched with each other. Softwares having the same product codes cannot be installed toghether.
Here is the trick to make upgrade you software:
<Upgrade Id="$(var.UpgradeCode)">
<!-- Detect older product versions -->
<UpgradeVersion OnlyDetect="no" IncludeMinimum="yes" IncludeMaximum="yes" Minimum="0.0.1" Maximum="$(var.ProductVersion)" Property="PREVIOUSVERSIONSINSTALLED"/>
<!-- Detect newer product versions -->
<UpgradeVersion OnlyDetect="yes" IncludeMinimum="no" Minimum="$(var.ProductVersion)" Property="NEWERVERSIONDETECTED"/>
</Upgrade>
<!-- Exits successfully in the case newer version are already installed -->
<CustomActionRef Id="WixExitEarlyWithSuccess"/>
By using the above markup, you say to Wix abort installation when he find a product having the same UpgradeCode but the installed one has a Version greater than the current one, but begin the installation (upgrading the current one) if he find a product having the same UpgradeCode and the installed one has a Version less than the current one.
The IncludeMinimum and IncludeMaximum shall do the trick, allowing the upgrade to skip the current version.
Wix doesn't install the same product: you shall be sure that the product code is the same for installed software and MSI-packaged software: if they are different, they are different deployed softwares. Beyond this, if the product has the same product code of the MSI, the installation offers the repair/change options: to disable them you have to play with the Property table of the Wix package, by introducing the ARP_ variables (you can disable repair, change and uninstall, but also setup manufacturer contacts and other properties).
Here is the ARP variable list. I don't know what is their behavior when installing in silent mode, but if you are invoking msiexec from command line, there is a specific repair option to issue repair (/f), so how can it automatically repair your product if you are not requesting?
This cannot be done.
When trying to install an already installed package, Windows Installer automatically performs a repair. There is no upgrade process.
Also, the maintenance process is triggered based on ProductCode. When launching your package the second time Windows Installer sees that its ProductCode is already installed and enters maintenance mode. It's not related in any way to upgrades.
Upgrades are used only when changing the ProductVersion and ProductCode.
Edit:
To prevent an automated repair in maintenance mode you can try this:
write a win32 DLL custom action which detects if the product is installed or not
if it is, this custom action should return 1602