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.
Related
We have a custom WIX bootstrapper installer. Bootstrapper bundle chains 3 individual application msi. Bootstrapper custom UI allows user to choose which application to install and based on the selection custom bootstrapper will install its msi.
Now consider the scenario.
Application, say A1 version 1.0.0.50 is installed in the system. Assume bootstrapper version is also 1.0.0.50
Assume next version of bootstrapper installer with some updates is available, Assume its version is 1.0.0.51.
Using this one I want to install second application , say A2.
Also I want to uninstall A1. Currently we support upgrading A1 to 1.0.0.51 version using this latest installer.
But I want to check the possibility of uninstalling A1 using the latest bootstrapper version. How do I implement it?
Because as per our project requirements, end user should be able to uninstall A1 using any version of bootstrapper.
I have seen in registry it stores the Uninstallstring for each msi. If I run uninstallstring value , for e.g MsiExec.exe /X{90140000-0011-0000-0000-0000000FF1CE}
Will it exactly does what is done by msi uninstall ? will it handle cleaning registry entry entries, deleting installed files etc ?
Don't go to registries for this. MSI database has an upgrade table which will hopefully fulfill your requirement(https://msdn.microsoft.com/en-us/library/windows/desktop/aa372379(v=vs.85).aspx). Add an entry with Upgrade Code of installed MSI, provide version boundaries under VersionMin & VersionMax, set the attribute 769 or something else depending on your requirement, create a new public property and add it to SecureCustomProperties.
Lastly during installation enable windows logging and check the logs for standard actions like findrelatedproducts and removeexistingproducts if you face any issues.
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)
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 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.
My company uses Wix 2.0 in the build chain.
When our users try to install a later build over an older one, the old build is replaced IF the major version number is the same. Otherwise, we let them have a side-by-side install so they can evaluate the new version before buying (no charge for minor version number updates).
However, I'd like to offer the user the choice of replacing any previous version.
From what I know of Wix, this would mean making the OnlyDetect attribute of the UpgradeVersion element dynamic somehow.
Is this possible without a custom action that hacks the table? The msi will be launched from a .exe gui so I can set properties and the like.
You don't want to use OnlyDetect. You author the Upgrade element (or use the helper MajorUpgrade element if using WiX v3.5+) to do the upgrade and then condition the RemoveExistingProducts action. No hackery necessary.