I'm trying to find out if it is possible to create a burn bootstrapper exe where the chain bundle references non-existent msi packages. In this scenario I'll be using the compressed="no" attribute so the set of msi packages I want installing will not be embedded but will be alongside the bootstrapper.exe
However at the time of compiling the bootstrapper.exe the msi packages to be installed do not yet exist - However they will do at a later date...
The msi packages have well known names that won't change, and will live in a well known location relative to the bootstrapper.exe - they just arent available at compilation time.
Does anyone know if this is possible with wix burn?
Thanks
As far as I know it is impossible - but - you may use some "placeholder" msi files - just for sake of compilation.
Of course if you do so- the data that the bootstrapper builds-up - like the msi installation sizes, the msi file sizes, the feature lists and so on will not ba avialable...
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.
I have a WIX Bootstrapper Burn bundle which contains 4 MsiPackages and has been released in production. Our latest version of the bundle is to no longer ship one of the packages and should uninstall the package should it exist. What is the best way to uninstall the MsiPackage without providing the entire msi in the bundle?
I have tried:
Removing the PackageGroup from the chain entirely - This leaves the product behind.
Adding the MsiPackage and setting the installlevel to 0 - This needs a very large payload as the msi that is being removed is large.
I also tried using product search to find the state
<util:ProductSearch Id="AppX" UpgradeCode="XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX" Result="state" Variable="APPXSTATE" />
but tried to hook it up to an ExePackage to run msiexec /x UpgradeCode but I figure is the wrong way to uninstall.
Whats the best way for me to purge msi with UpgradeCode X if it exists in this newer burn installer?
Thanks
Note: I am not aware of any auto-magic constructs to use in collaboration with util:ProductSearch to uninstall existing MSI
installations.
Upgrade Table: I assume the four different products have different upgrade codes "per family"? If so - and if you are positive it will never need to be installed again - then I suppose you could specify that it should be uninstalled via a major upgrade for one or more of the packages you will keep delivering. Note: It might be possible to uninstall even if all setups share the same upgrade code, but that requires a lot more care and testing.
This solution involves adding the upgrade code for the MSI you want to remove to the upgrade table of those MSI setups you want to preserve with a version range specified that will uninstall all "known prior editions". Technical details for how to do this can be found here: Adding entries to MSI UpgradeTable to remove related products. As stated it is enough to do so for one of the products that will remain, but you can do it for all of them to be sure. No errors should result if the product has already been uninstalled. I might want to set a tighter range than what is shown in that technical sample for the versions targeted.
ExePackage: It should be possible to uninstall as you have suggested by using an ExePackage instead. It could run msiexec.exe directly I suppose, or maybe launch a VBScript, Powershell script or even a batch file or your own EXE file compiled from C++ or C# (the latter with unfortunate runtime requirements). I have never tried this approach.
Please note that you do not uninstall by upgrade code in the fashion you do with msiexec.exe /x UpgradeCode - at least I have never been able to make that work (not tested for a while). Instead you need to uninstall via product code (How can I find the product GUID of an installed MSI setup?), OR you can use VBScript and MSI API automation to uninstall by using the Installer.RelatedProducts function and then kicking off uninstall that way as shown here: Powershell: Uninstall application by UpgradeCode. This is similar to what happens when Windows Installer processes the Upgrade Table. All releated products - those sharing the same upgrade code - are enumerated and you can handle them as you do so.
Some Links:
Powershell: Uninstall application by UpgradeCode
WIX (remove all previous versions)
Wix upgrade goes into maintenance mode and never does upgrade
I have a bootstrapper that only wraps one MSI. I might prefer to give the MSI to customers who I know have already run the bootstrapper and have the prerequisites installed. But running the MSI leaves the original entry in Control Panel alongside the new one, even though the UpgradeCode code is the same for Bundle and Product.
I understand there are some issues here - the bootstrapper is not the MSI, and in fact may contain more than one MSI. So I imagine this is actually expected behavior.
Is what I want to do just considered a bad idea? Should customers who install with a bootstrapper always upgrade with a bootstrapper?
If you don't upgrade a bundle with another bundle, the old bundle's registration (more than just an ARP entry) and package cache is left behind. So yes, standard behavior is to upgrade with a newer bundle. If you are just trying to save download bandwidth, you can distribute an uncompressed bundle (just the bundle .exe with no embedded packages); only the necessary payloads will be downloaded and you won't waste bandwidth downloading prerequisites that are already installed.
Is there a reason that the bootstrapper is an exe as opposed to an MSI? And, is there a way to instead generate a MSI?
I need to have multiple localizations of the bootstrapper and would like to apply transforms like can be done for a WiX MSI. And, since the bootstrapper uses the same localization files it'd be nice to be able to use the same approach for the bootstrapper as for an installer.
Many of the things being bootstrapped are MSI based, and you can't really run an MSI from within an MSI install. Bootstrappers are typically executables that contain one or more embedded MSI files - the executable checks if the prerequisite is installed or not, and if not launches the appropriate MSI installs, patches, whatever else is in there.
Am new to Wix, i have a situation where in i have 2 different addins that has been developed using the adx com addin, and now there is a need for release where in a single msi file should install these 2 addins (i have created 2 different addins).
Could you please suggest if i can install these 2 addins in a single wix installer. keeping in mind that these 2 addins will have a seperate registry entry in the registry.
or, i can bundle these to msi inside a single msi file using the bootstrapper.
2.1. i used the chaining functionality with MSIPackage element and the project built successfully, but on installing this msi, there was an error " This installation package could not be opened. Contact the application vendor.......", further analyzing the issue, i understood its because there is no entry point defined for a msi file. i was able to achieve this as an exe, but the client prefers an msi rather.
Any help appreciated.
Thanks in advance.
You can add your adx com addins as two separate features in one wix project, and then a single msi can install both for you, it doesn't matter that there would be separate files or registry keys.
Why does your customer want an msi? If you do use burn, the executable is still executing separate msi's and so you will still have the benefits of using windows installer, even though the containing file is an exe bootstrapper.