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.
Related
I have a wix bundle which has say 4 MSIs - all with version 1.0.0 and Bundle version as 1.0.0. I install this on a windows machine and in the ARP I see the WiX bundle as 1.0.0.
Now I make some changes to only one of the MSIs, say B, and change the Bundle version to 1.1.0 and the changed MSI (B) version to 1.1.0. The rest of the MSIs (A, C, D) are still at 1.0.0.
Now when I run the bundle again, I expect that installation for A, C and D would be skipped and only B would be upgraded and the bundle will also be updated with version 1.1.0 in the ARP. But what I observe is that installation for all the packages (A,B,C,D) take place and not just B.
So is my expectation wrong or am I doing something wrong?
This is what I have in my bundle code
<Chain>
<MsiPackage Id=“A"
Cache="no”
Vital=“yes"
EnableFeatureSelection="no"
Permanent="no" Visible="no"
ForcePerMachine=“yes”
SourceFile = “<>”/>
<MsiPackage Id=“B"
Cache="no”
Vital=“yes"
EnableFeatureSelection="no"
Permanent="no" Visible="no"
ForcePerMachine=“yes”
SourceFile = “<>”/>
</Chain>
And this is what I have in my wxs for the individual MSIs. I change the version to 1.1.0 only for MSI B and keep the UpgradeCode same.
<Product Id="*" UpgradeCode="<GUID which is same across installations>"
Version="1.0.0" />
<MajorUpgrade DowngradeErrorMessage="New version is present."
I looked up many threads but generally they talk about upgrading all the MSIs, just not 1 MSI. Let me know if something is unclear and thanks in advance for your help.
Burn won't install a package if it's already installed. But if you rebuild a package with Product/#Id="*", the package identity changed (both product code and package code). So Burn installs what looks like a new package. If you want Burn to skip such a package, don't rebuild it.
Part of the majorUpgrade Element there is a AllowSameVersionUpgrades attribute, with default value no.
Meaning "When set to no (the default), installing a product with the same version and upgrade code (but different product code) is allowed and treated by MSI as two products. When set to yes, WiX sets the msidbUpgradeAttributesVersionMaxInclusive attribute, which tells MSI to treat a product with the same version as a major upgrade."
Check this attribute and see if it helps with your issue.
The best practice is to change the version to all msis and the bundle, this is done automatically part of the CI/CD pipeline of releasing the product.
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.
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.
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've been asked to bundle Apple's Bonjour installer into our own msi installer, so that Bonjour automatically gets installed alongside our software. Anyone done this before? It doesn't seem to be trivial, as an msi installer cannot include and kick off another one. I assume I'd need some kind of batch file to run the two installers sequentially?
You'll need to use a bootstrapper to chain the Bonjour install with your installer. If you are using WiX 3.6 or later, using Burn to create a package bundle is a good option.
I found the Bonjour installer by downloading the Bonjour SDK and opening it in 7-zip, though I'm sure installing the SDK would provide access to it as well.
The way I typically like to do this is to add a new source file to your setup project for each dependency package to keep that logic separate from the main application setup.
The Bonjour package can be listed as a remote payload to retrieve on the fly, or build it into your setup. In this case, it seems more likely to build it in (Compressed="yes"). If you need to add any extra dependencies related to bonjour or parameters to pass into it, you could define them here as well.
<Fragment>
<!-- if a web link actually exists, I didn't find it... -->
<?define BonjourWebLink = "http://path/to/Bonjour.msi"?>
<PackageGroup Id="BonjourWeb">
<MsiPackage Id="BonjourWeb"
Compressed="no"
DownloadUrl="$(var.BonjourWebLink)">
</MsiPackage>
</PackageGroup>
<PackageGroup Id="Bonjour">
<MsiPackage Id="Bonjour"
Compressed="yes"
SourceFile="path\to\Bonjour.msi"/>
</PackageGroup>
</Fragment>
In your main bundle you just need to add a reference to the correct package group.
<Chain>
<PackageGroupRef Id="Bonjour"/>
<MsiPackage SourceFile="path\to\YourProduct.msi"/>
</Chain>
Since Bonjour uses MSI instead of an executable, you don't need to do anything to detect whether it is present or not; Burn will handle that for you. Actually, since WiX harvests most of the information your bundle needs from the MSI, this might be overkill, and you could just put in the MsiPackage element in your chain directly.
Don't forget to carefully check Apple's terms for doing this.
This would be a bit more work, and is prone to issues with upgrading, but you can take the Bonjour MSI and decompile it using dark. Convert the decompiled MSI into a Merge module that can be included with your installer, and you will have a single install. I have done this with some driver installs in the past, and it is usually not that complicated.
You need a bootstrapper; there are several freely available out there, including one being developed in WiX called Burn.
Wix Burn is relatively stable now.I`m using Wix 3.8.
If you are allowed to redistribute Bonjour Installer,you can chain the installer in Wix Burn. You can even put a condition to specify Bonjour as prerequesite for your installer.If it is not present,then Bonjour will be deployed, else it can be skipped.
You can check this link for understanding Burn.
http://wixtoolset.org/documentation/manual/v3/bundle/