I have a wix project which builds msi for my application.
This installer has upgrade code 1.
Sometimes It requires administrative permissions to be run.
That is why I'd like to add setup.exe which will run the msi.
The only one way I see to create Bundle.
I.e.
1. wixproj builds MSI (upgrade code 1)
2. wixproj which builds bundle package including msi (p.1.)(upgrade code 2)
These projects have different upgrade codes. How it will work if run on machine where the old product already installed with upgrade code 1 and was installed without bundle?
Bundle upgrade codes are distinct from MSI package upgrade codes. Burn lets the package upgrade itself.
Related
I have a bundle which installs two products: the application and a much larger resources installation.
For upgrades the application msi will apply a standard upgrade, but the resources installation gets patched instead. (Unfortunately this process started a while ago, so the patch chain is still built using Wix 3.0).
On uninstall of the bundle the application is fully and correctly uninstalled, but the patch only is removed, leaving the full install of whatever previous version of the resources existed (downgrade from 1.5.0.0 to 1.4.0.0).
Is there a method to force a full uninstall of the full product, rather than just the .msp patch, through the bundle?
Edit: Just to add, exposing the resources installation in Programs and Features and running an uninstall there will remove the entire product correctly as expected.
I think this could be a possible solution for you.
I just tested myself a very simple bundle with one MSI in it. What I did was have the main bootstrapper installer have the msi embedded in it an install it. The second bundle had a higher version and the exact same msi reference but I set compressed="no" in the <MsiPackage> tag. When I uninstalled the upgraded bundle it also removed the original MSI.
So I think you can get your bundle to properly remove the original "Resources" installation after you've upgraded and added a small msp. You just need to add back the <MsiPackage> to the bundle chain before the msp and set compressed="no"
<MsiPackage SourceFile="$(var.ResourcesInstaller.TargetPath)" Compressed="no"/>
The only caveat here is that the SourceFile should be the exact same msi that was included in your first install. When you install the upgrade, the burn engine should detect this msi as already installed so nothing would be needed to be done. When uninstalling, it will detect the msi as installed and should uninstall it.
I'm not completely sure this will work but it is something to try. Another nice thing about this is it will have virtually no impact on the size of your upgrade installers.
I have created a Wix custom bootstrapper application and bundle file using Wix 3.8. Bundle file contains five MSI packages. Created a setup and installed it. All MSI packages are installed and uninstalled correctly.
Then, I have include "InstallCondition" attribute in each MSI package elements in bundle file. Installed the setup based on the selection (installed three MSI packages). Installation working fine.
Now I want to uninstall any of selected MSI packages from installed packages (three packages installed) using custom BA.
Is it possible do the above using Wix CBA? Please share any idea regarding this.
Thanks
You need to call Plan with the Modify action (or Uninstall if you want to uninstall the whole bundle). Then in the OnPlanPackageBegin callback, set the desired state of the package (Absent to uninstall). I think if the InstallCondition of a package evaluates to false during a Modify or Uninstall action, the engine would plan to uninstall it by default.
I have a WiX project that creates a product installer for Windows (.msi package). Now I have a scenario where I need to create an update package (on Windows) that only works if the product is installed on the client machine, but in any other case it simply exits.
Most likely I need the Upgrade feature (<Upgrade ... />) in WiX, but how do I do that?
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.
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.