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.
Related
When installing my software I need to take care another msi package is uninstalled before. Is this possible? Can burn do this for me?
MSI / Major Upgrade: You can add entries to the Upgrade table in one or all of the MSI files you install. Then the older / other MSI will be uninstalled before (or after) your MSI is installed. This is MSI's built in "major upgrade" feature intended to deliver upgrades for your own products, but you can uninstall any product you want that is MSI-based - even a competitive product - only if you are nuts, and do call legal first :-). Maybe see this description (related problem at least): Adding entries to MSI UpgradeTable to remove related products.
Burn: Burn can run EXE files that can initiate uninstall of pre-existing MSI files, but I would never choose this approach when you can use the above built-in MSI approach instead. I am not sure if you can call msiexec.exe directly via the ExePackage element of Burn, but you trigger the uninstall from within a custom made EXE file in a myriad of ways: Uninstalling an MSI file from the command line without using msiexec. It depends what your EXE is written in. If it is managed code, maybe use the DTF method (option 6 in the linked answer). If it is C++, maybe use the MSI API Win32 functions. See option 14 in the linked answer. I guess you can also chose to shell out to msiexec.exe (option 3). My advice: always go native code for deployment. Your setup must work on any machine, in any language, in any state and in any OS edition. There are many further variables. Minimal dependencies is the only cure.
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 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 created one msi for my product it's working well but I need to install .net 4.0 as a prerequisite. I came across burn and bootstrapper but have a couple of questions:
Should I have a separate project for the main msi and the bootstrapper?
My customer needs an msi (not an exe), so can the bootstrapper be an msi?
The bootstrapper project is a separate project and produces an .exe as its output. It is its own executable, whereas an .msi is essentially a database that gets processed by Windows Installer.
MSI (Windows Installer) does not support "nested" installs, where one .msi package runs for a while, then pauses, runs a separate installer package, then picks up from where it paused. MSI uses some Windows resources that are essentially system-global, so the "inner" install tromps on the "outer" one.
The way to do multiple installs as a single user experience is to run each install in sequence, one at a time. That is the purpose of the bootstrapper, also known as a chainer: to run the chain of installs, link by link. The bootstrapper is not itself an install package; it is a tool for running one or more install packages.
That is why the bootstrapper cannot be an .msi: it is not itself an installer package. A bootstrapper can be as simple as a batch file or script, or you can use an industrial-strength tool such as a WiX burn bundle, Flexera AdminStudio, etc.
Be aware that there are some installer packages that ship as .exe -- for examples, the .NET Framework or SQL Server installers. These are essentially self-extracting archives that contain one or more .msi packages, dump a temporary copy of that payload then run the Windows Installer service on it. In some sense they are "bootstrappers" plus package, all rolled into one. A bootstrapper can run packages (and other bootstrappers), but not vice-versa.
You might think that you could have your outer package run a custom action that launches the inner package. We've all tried it... and found out the hard way that it doesn't work generally, even when you appear to get away with it on some specific target system.
You'll have to persuade your customer that Windows Installer does not, cannot, work the way he thinks it does. Sadly, sometimes the only way to do this is to replace the customer.
Are there are any templates or guidelines for creating a Windows Installer XML (WiX) project for deploying a Petrel plugin?
Are there any reasons for WiX not having been selected as the natural successor to the old *.vdproj/MSI recommendation?
Has anyone tried WiX for Petrel plugins? I'm interested in exchanging ideas and experiences. I'm new to WiX, and find it difficult to get started.
(Off topic: the "new" PIP paradigm is lean and simple, but is a bad fit for enterprise use, where clients expect to be able to repackage an MSI in order to facilitate mass deployment through e.g. group policies. I'll post another question on this.)
MSI deployment is still supported in Ocean/Petrel regardless of the way of MSIs generation (and WiX is just another way to generate them).
In Ocean/Petrel 2012.1 you need to define custom action calling command-line tool PluginManager.exe with /install and /uninstall switch during the installation and uninstallation steps respectively. Custom actions are defined using <CustomAction> tags in WiX. There are two tricks you need to keep in mind when calling PluginManager.exe from MSI custom actions:
you need to supply your MSI installer ID (usually GUID) in /installerId:your_installer_id command-line switch during the installation. This will enable automatic MSI uninstallation of your plug-ins when Petrel is uninstalled
you need to run PluginManager.exe with /runFromInstaller switch during the uninstallation. By doing this you let PluginManager know that you run it from MSI installer, and so there is no need to run MSI uninstallation once more
You can find these and other tips and tricks, with full PluginManager.exe command line speicifications in the Plug-in Identity and Deployment White Paper in Ocean.chm (section "How to use PluginManager.exe in MSI installer").
Important information with Petrel 2013:
We have plugins that can be installed or uninstalled using MSI, created with Wix. When installing a PIP with PluginManager.exe without using the argument /installerId:<msi_installer_id> uninstalling the plugin using the Petrel physically deletes all your files, but create an inconsistency in windows uninstaller plugin. If we use the argument /installerId:<msi_installer_id> uninstalling the plugin using the Petrel occurs only logical deleting the plugin, keeping it physically in their original directory. This allows it to be installed subsequently also by Petrel. In the latter case, there is no inconsistency, because the windows uninstall the plugin and be able to delete all your files.
The problem is that uninstalling the plugin using the Petrel 2013 is not calling its MSI uninstaller. It should not be? This looks like a bug.