I have a bootstrapper which is built using Burn and installs a package which i have setup to allow for minor upgrades when i run the msi packages using REINSTALL=ALL REINSTALLMODE=vomus from the command prompt (as per this article in the WiX docs).
However currently trying to upgrade with the setup.exe returns the message "Another version of this product is already installed..."
How do i get the boosttrapper to upgrade it's packages?
According to this question from 2009 burn "will be able" do the work of starting the MSI in the appropriate mode can it do it now?
I have tried using the MsiProperty element like this:
<MsiPackage Id="PackageId" SourceFile="path\to\my.msi">
<MsiProperty Name="REINSTALL" Value="ALL"/>
<MsiProperty Name="REINSTALLMODE" Value="vomus"/>
</MsiPackage>
But that doesn't seem to do it. What have i Missed?
If you are doing a minor upgrade Burn will automatically detect that and
pass the right switches for you. If you are trying to force it Burn does not support that.
Related
I have two products which I'm trying to write an installer for. Both products are wix bundles which both have a third product bundle as a requirement.
Ideally what I want to happen when you install one is:
If Product3 is not installed then it should be.
If Product3 is installed and installed version is higher or the same do nothing.
If Product3 is installed and installed version is lower then upgrade.
If uninstalling and product1 or 2 is still installed do not uninstall product3.
So far I was able to conquer some of these points but not all at the same time.
Originally I tried getting the installed version using a ProductSearch and using InstallCommand. However I ran into problems with uninstalling when doing side by side installs because the installcommand is more like "requested install state" and so if I don't want it to install when it detects the same version it actually starts uninstalling it.
I took a look at this similar answer:
How to avoid uninstalling previously installed ExePackage (redistributables) while installing a WiX Bundle?
which suggested using the provideskey and requires elements but I cannot find any useful documentation on them whatsoever. I tried experimenting with it but it doesn't seem to do anything at all.
I've looked at RelatedBundle but I'm not sure it's what I'm after. Seems more targeted at hotfixing systems.
I was hoping there was a way of doing this without having to resort to custom actions since that seems a bit extreme for what seems to be rather simple functionality.
After a lot of trial and error I figured out how to get the DependencyExtension working.
In the example below ProductC is a Wix Bundle executable. This bundle includes an MSI file. I use a productSearch to look for the upgrade code of that MSI file (NOT THE BUNDLE) to detect if it's already installed.
In your bundle file for project A and B:
<Wix xmlns:dep="http://schemas.microsoft.com/wix/DependencyExtension"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Bundle>
<util:ProductSearch Id="ProductCInstallSearch"
UpgradeCode="{ProductC_MSI_UpgradeCode_GUID}"
Variable="ProductCInstalled"
Result="state"/>
<dep:Requires Id="ProductCRequired" ProviderKey="ProductC"/>
<Chain>
<PackageGroupRef Id="ProductC_pkg"/>
</Chain>
</Bundle>
<Fragment Id="Required_Pkgs">
<PackageGroup Id="ProductC_Pkg">
<ExePackage Id="ProductC_Bundle"
Permanent="no"
DetectCondition="NOT ProductCInstalled = 2"
InstallCommand="/quiet"
UninstallCommand="/uninstall /quiet">
<dep:Provides Key="ProductC"
Version="0.0.0.0">
<dep:RequiresRef Id="ProductCRequired"/>
</dep:Provides>
</ExePackage>
</PackageGroup>
</Fragment>
</Wix>
Now you can install A and B in any arrangement and when uninstalling product C will only be removed when the last one is uninstalled.
We are upgrading our WIX msi installer (not a bundle) with manual pre-requisites to a Managed custom Bootstrapped application Bundle. The boot strapped custom installer bundle exe works fine for fresh installs. But if we want to upgrade our older product which is just an msi, we are in trouble. This is what I am trying to do
Detect RelatedMsiFeatureHandler detects there is an older msi package installed.
I am handling the Plan events for individual packages and setting the states as desired. For ex: state = Present for install
I cannot to Apply(UpdateReplace) because I do not have an older Bundle,
The million dollar question is how do I upgrade this msi package?
Any help is appreciated.
Thanks
All I had to do was set the MsiProperty UPGRADE=1 in Bundle.wxs for the relevant Msi Package in the chain. This made sure that when the Bundle.exe is run the specific msi is upgraded BTW: this is the first version of Bundle for us. We had just an MSI before for installation.
<MsiPackage DisplayName="Installing Main Product" SourceFile="$(var.Path_Setup)" DisplayInternalUI="no" SuppressSignatureVerification="yes" >
***<MsiProperty Name="UPGRADE" Value="1"/>***
<MsiProperty Name="NAS_PATH" Value="[NasBackupPath]"/>
<MsiProperty Name="NAS_BAK_TIME" Value="[BackupTime]"/>
</MsiPackage>
</Chain>
Just in case if anyone having similar issue (WIX 3.10)
this statment under the installer's Product will resolve the issue. You must update the version of the product and product upgrade code must be same with previous install.
"AllowSameVersionUpgrades" = yes will make sure not to install same product side by side.
We have a busted MSI in production that needs to be fixed via msiexec /fv package.msi before it can be properly upgraded.
I was hopeful that we could wrap this procedure in Burn but this Q and response from Rob appears that it might not be possible.
I tried:
<Chain>
<MsiPackage SourceFile="fixed-package.msi">
<MsiProperty Name="REINSTALLMODE" Value="v"/>
</MsiPackage>
</Chain>
But nothing happened.
I only need REINSTALLMODE=v and not REINSTALLMODE=amus as mentioned in the linked question, so I'm not sure if that makes a difference. The broken package has bad conditions that prevents uninstall and upgrades and this new one fixes that.
Have things changed in Burn since May '13 that recaching an existing MSI is now possible?
Thanks
You can also do it with a custom action. Just have the MSI extracted as temporary file in the beginning of the install for the new version, then execute a custom action to recache it, after which continue the installation. This is how I have done it so far.
However, I don't know if Wix has support for temporary files like Advanced Installer does (which is our tool), so you might need to build a custom action for that too.
Im using WiX to install my .msi, I´m generating a WiX Bundle using the Bundle Element.
I try to not show the Bundle on "Add/Remove programs" so i set the properties of the Bundle element like this:
<Bundle Name="$(var.ProductName)" Version="!(bind.packageVersion.MSIPackage)"
Manufacturer="$(var.ProductManufacturer)" UpgradeCode="$(var.UpgradeCode)"
DisableRemove="yes" DisableModify="yes" DisableRepair="yes">
DisableRemove, DisableModify and DisableRepair to "yes" made the Bundle be hidden under "Add/Remove programs".
My problem is that when i Uninstall my application, the application is uninstalled correctly but the Bundle remains Hidden, so it cause some problems when i try to install other version of the App, for example the new Bundle detects that there are other Bundle installed and performs some versioning check and so on.
So my question is: is possible to when the application in uninstalled from the "Add/Remove programs" uninstall the Hidden Bundle as well?
To expand on Tom's answer, if you remove the Disables from your Bundle tag
<Bundle Name="$(var.ProductName)" Version="!(bind.packageVersion.MSIPackage)"
Manufacturer="$(var.ProductManufacturer)" UpgradeCode="$(var.UpgradeCode)">
You can modify your MsiPackage tag to hide the MSI from Add/Remove Programs
<MsiPackage
Id="YOUR-ID"
Vital="yes"
DisplayName="$(var.ProductName)"
SourceFile="$(var.Source.TargetPath)">
<MsiProperty Name="ARPSYSTEMCOMPONENT" Value="1"/>
</MsiPackage>
This will leave just one entry in Add/Remove Programs. Your Bundle will now handle the UI of the install and uninstall, and will correctly allow other versions of the bundle to be installed.
Well, you could use a custom action in the msi but don't.
You have inverted the designed relationship between bundles and packages. I suggest that you hide the package and show the bootstrapper in ARP.
The bootstrapper engine ("burn") is a package manager that collaborates with Windows Installer. Together they handle upgrades and uninstallation of packages. If, after understanding how it works, you don't want what it does then you may want a self-extractor instead of burn. (Some projects that do use burn are Visual Studio and WiX itself.)
Use -repair option when running the installer every time. It's a hack but it works. The problem is that the bundle uninstall is hidden, and when running uninstall you are only removing the package inside, not the bundle.
This causes the issue when you want to run the installation again after uninstalling the package inside. The installer thinks that the bundle is still installed. By using the -repair option (every time you install the bundle), you are telling it to either install the bundle if no bundle is present. or repair it if the package was removed.
-repair = repair (or install if not installed)
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" />