I am using Wix 3.8
I want to have a single installer UI which will present four applications.Based on user selection
the particular application has to be installed/ uninstalled /upgraded.
So I added four msis in a custom bootstrapper bundle. In the Custom UI we show all four application names
and based on the user selection I set bundle variable value. Install condition attribute is set to this bundle variable.
Also based on the user selection package list will be updated to have only the relevant package(s) .
In this way install is working fine. Install add only the bundle entry in the Add /Remove Programs; and not individual entry for each msi.
I am also able to manage uninstalling a package based on the user selection.
The issue is while uninstalling one msi package it removes the entry of the bundle from Add/Remove Programs list.
Now how do I uninstall other packages?
The behavior what I need is I want to retain the bundle entry in the Add/remove Programs list ; Once the last package is also uninstalled I want to remove the
entry from Add /Remove Programs List. Please advice me how to achieve this?
I'm going to suggest a different way to approach this problem because it seems to me, and I may be way off base here, that you are implementing something using a bootstrapper when you may only need a single MSI that uses a FeatureTree.
A feature tree can list various categories of things to install or not install. For example, it might ask if you want to install:
Framework only?
Framework and Tools?
Only Tools?
And if the user chooses Only Tools and later decides they want Framework, they can go to Programs and Features, click Change and then they'll be able to select the Framework feature from the Feature Tree.
And if they want to uninstall one thing or everything all together, they can do that too.
If you have control over the four MSIs that you mention, you could change them to be Wix Library projects instead. That would allow you to keep developing them separately, by different teams, but have them all referenced in one MSI project.
Related
We are using the WIX Toolset among other things to automate a long installation process. A big part of this is installing lots of prerequisites that change based on what version of the product the customer wants to install.
e.g. there is a filter pack (.msi file) involved in the installation that only needs to be installed with a certain type of the product, so it is impossible to simple chain it into a bundle because we cannot know in advance which version the customer chooses.
Is there any way to solve this problem without having to create 4 different installers or installing all prerequisites regardless of version?
Thanks in advance.
The easiest and most maintainable (imo) method for implementing this is to use a burn bootstrapper and have a separate msi install for each version of the product the user could install.
The burn boostrapper would also contain all the prerequisite packages needed but only install the ones required by the specific version the user chooses to install.
You say you can't include the filter pack in the chain because you don't know until runtime whether or not the customer wants it but that's the whole point of the bootstrapper. Your bootstrapper should gather the information at runtime and set variables accordingly. Using the InstallCondition on the MsiPackage element you can determine whether or not you need to install the msi or not.
The bootstrapper process is to run Detect, do the UI, Plan, Execute. During Plan you will figure out which packages will be run and installed during the installation. The bootstrapper application has the authority to set any package to install or uninstall, overriding whatever the engine decides to do.
You could also include all the msi version stuff in one MSI and control it via feature groups which would allow you to use one MSI fo all the versions of your product but this can get bloated and complicated with multiple 'duplicated' components from different versions of your product so I think this would become a maintainability hell later on.
You can add a custom dialog which has checkboxes where the user can choose what to install.
These checkboxes set a variable to 0 or 1. You can use these variables in the installcondition.
I believe you can even conditionally show checkboxes(say 2 off the 5 are already installed, you would not want to give the user the option to install the already installed 2)
We've used wix to create our installer for some time now, but previously we've relied on our customer installing SQL themselves.
I now want to include SQLLocalDB for our smaller customers as an option in our installer, but I don't know the correct way to implement this.
I've added radio buttons to our product to chose between using SQLLocalDB or an external server but how do I pass this variable to the bundle's InstallCondition for SQLLocalDB. I Tried using the registry in between but the registry is read as soon as the bundle msi is started and not after the first package has been installed.
My first idea when I started implementing this was to install SQLLocalDB, create the database and the tables from a custom action, but I've now realized that isn't possible
So to finalize my questions:
How do I add optional features correctly?
If I want to create the database and create/update the tables, do I have to create yet another msi for this and add it as a third package in the bundle?
We have two WiX installers that use our own BA. One installer gets all the packages from the web, while the other gets all the packages from the exe. We call them "Web" and "Full" installers.
We have a case where a user might install one package from the web installer and a different package form the full installer. It probably won't happen often but it could happen. When the user does this, we have two entries in the Add/Remove programs control panel. Since we didn't name the installers differently, it looks like the installer is installed twice.
My question is, if the only difference between two installers created with WiX is the way the packages were acquired, shouldn't it just appear once in Add/Remove programs? Do I need to set a code somewhere to say it is the same installer?
I guess we could just name them differently so that a "Web" and a "Full" installer appeared in Add/Remove Programs, but when you run either one, both packages show up for uninstallation because both installers know about them. It's not like the web installer only shows the package that was installed through it and the full the package that was installed through it.
Any comments are appreciated.
In a version upgrade scenario, using the same UpgradeCode for both <Bundle...> packages is enough to indicate both installers are the same product. For example, if you first install package V1.0 and later install package V1.1 (where both packages use the same upgrade code) Package V1.1 replaces Package V1.0 in Add/Remove Programs.
Unfortunately the burn engine does not support same version upgrades. If you have different packages with the same upgrade code and the same version, both packages will appear in Add/Remove Programs. For more information on burn not supporting same version upgrades see: http://wixtoolset.org/issues/3746/.
Installing two different packages with the same upgrade code and version is well behaved. For example, if you install both packages and subsequently remove one of them, the resources in the first package remain installed, even though the same resources are also in the second package.
Installing two different packages with the same upgrade code and version, then later installing a third package with the same upgrade code but a higher version is also well behaved. The third package replaces the first two packages!
Your suggestion of varying the name of the packages to differentiate them in Add/Remove Programs sounds the most pragmatic way forward. Having two entries does not appear to compromise the installation state, and upgrades appear to be handled without issues.
I maintain two flavors of an application. Only one should be installed on each machine.
Let's say that I got application A installed on a machine. Now the user wants to install application B. The installer should replace A and install B.
Is it possible to tell the windows installer via WIX to silently replace another application?
You can actually do this via the same mechanism that supports a major upgrade. Give each MSI a unique UpgradeCode. Then add an Upgrade element that detects the other MSIs UpgradeCode. Then add an UpgradeVersion element that will detect the other MSIs version correctly (could be the version number). You can use the Property attribute from the UpgradeVersion element to display special UI or otherwise condition stuff in your MSI to say, "Hey, I detected the other application".
I would suggest using the WiX bootstrapper functionality called Burn. You can create a bootstrapper (setup.exe) containing the logic for what packages need installed/removed.
I would like to create a installer (like BootStarper) to achieve following steps using WiX.
There will be a setup.exe file.
Upon Runnig this file it has to open a UI and show the list of softwares (MSI) available for installation.
The software products are grouped into two Group A or Group B.
Each group may contain Two or more MSI files (Both internal and third party files)
Allow user to Choose a group and one or more products to be installed.
Based on the selection, the products should be silently installed on the local system.
Shall I create a WiX project and display given products(MSI) as its features and can start a deffered custom action to install the seleted ones?
How to author my WiX project to choose the groups and then selected features?
Any help would be greatly appreciated.
Upgrade to WiX 3.6 (Beta) and take a look at the new "Burn" functionality.
You cannot use a deferred custom action to install another MSI because there is a mutex that enforces one running execute sequence per machine.
There is functionality in MSI 4.5 called multi-package transactions however MSI 4.5 may not be already installed on a 2003/XP/Vista Machine so you'd need setup.exe to boostrap it anyways.
Also "concurrent" installs are deprecated and should not be used to do servicing issues.
This is not something you can solve either with the stable WiX release, or Windows Installer.
You will need a separate bootstrapper to launch your MSI files. as the WiX bootstrapper, Burn is only in the WiX 3.6 beta release and not yet properly documented I would suggest trying something like dotNetInstaller.