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.
Related
Let's say that I have distributed a WiX Burn package with a certain upgrade code (I do not know any product codes). Let's say that I decide that moving forward, I want to move to an MSI package. The question is: how can I remove the previous Burn package given the upgrade code when I install the MSI package? I have given both the same Upgrade Code, but the MSI appears not to uninstall Burn by default.
You'd likely need to write a custom action in your MSI that walked through all registry keys under:
HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
and searched for a registry value "BundleUpgradeCode" with the value of your static UpgradeCode guid. When you find it, read in the value of the entry "UninstallString" or "QuietUninstallString". That's the command you'll need to execute in order to uninstall the previous bundle before installing your new MSI.
Caveat: there's no rollback support with this approach if you uninstall the old bundle and the new MSI installer fails. You'll end up with a machine that has neither of your products installed.
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 have created a wix installer project which is working fine. It installs my application on system easily. whenever if there is any change in any file or service, i uninstall msi from controk panel and installs new msi on system.
But whenever i install new msi, application's all setting change after new installation, that doesn't sound good. For sort out this, i am using Upgrade code in Product.wxs file. But when i install new msi after build, but is shows given error:
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel
So, i want to update windows application package whenever there is any change in files and with same Product id. I just want to update installed msi, dont want to remove that.
You cannot use the same ProductId to do upgrades, you need to change it. The best way is to set ProductId="*" and this will change it for every build. You will also need to increase the version number and this best done by using the main exe assembly version number. See http://wix.sourceforge.net/manual-wix3/major_upgrade.htm for more info.
You can use the same ProductCode to update an installed MSI. Basically you increment the ProductVersion, rebuild the MSI (with new PackageCode) and do a minor update with a command line such as:
msiexec /i <path to new msi> REINSTALL=ALL REINSTALLMODE=vomus.
In my experience this not commonly used because if you're going to rebuild the MSI you may as well upgrade with a major upgrade.
If all you want are updates to a few files and you're not ready to ship a complete MSI file, then that's what patches are for. Rebuild the MSI as above, then build a patch - the patch is the delta between the two MSI files, see docs for MsiMsp.exe.
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.