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.
Related
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 am currently using WiX Toolset to build my installer. This tool is very nice but recently I encountered a problem. When I installed my program with .exe, then upgrade it with .msi, there is a double-entry in Add/Remove Program. Is there anyway to prevent the installer add double entry? Thanks!
It's not clear from your post if you have followed the rules for a major upgrade, such as use the same UpgradeCode, new ProductCode and PackageCode, increment ProductVersion in the first three fields, have upgrade logic in place in the MSI (such as major upgrade element). You'd need to supply your WiX source for these in the old and upgrade builds to see the differences. A verbose log would also help, installing the MSI with a command line that includes /l*vx [path to log file]
If those rules have been followed, the main reason for failure to upgrade is the one was per user and the other is per machine (or vice versa). One context will not upgrade the other. If this is the case the log will have an entry somewhere with FindRelatedProducts referring to an installed product in another context.
All this also assumes that the original install you did was MSI-based underneath the exe. If it was not, and it was some other install software that is not using an MSI file then there is no such thing as an automatic upgrade. You'd need to find some none-MSI way to uninstall the older product. A typical way is to find the UninstallString in the registry for that product and run it. Depending on the software used, that command can be parsed to add a silent option.
I am having an MSI file which copies a set of dll from it source to destination folder. While running the MSI the dll are copied to the destination folder also the MSI is installed in the system. I can see that in ADD or REMOVE programs.
Whenever there is a change in dll, i copying the new dll and building the MSI again. When i tries to run MSI in the same system i am getting error "Another version is already. Uninstall that version and proceed" something like that.
What i am doing until now is uninstalling the old one (MSI) and installing the new one.
But i want the MSI to update the older dll with the latest dll from the MSI instead of uninstalling and installing again.
Thanks in advance.
You can't just rerun the MSI to do an update. There's some background here, even if you are not using Visual Studio setups, and it's still relevant after all this time:
https://www.simple-talk.com/dotnet/visual-studio/updates-to-setup-projects/
To replace a single file, build a patch, an msp file. To upgrade the entire setup, including that Dll then use the WiX majorupgrade element, and that may be a lot easier than building a patch, especially if your setup is small and doesn't take long to install. Increase the file version of the Dll to make sure it gets replaced.
welcome to StackOverflow - it seems to be your first post. I would read this thread if I were you to get an overview of how to implement a WIX major upgrade: How to implement WiX installer upgrade?. Here is another thread (didn't read this one through): How to get WiX major upgrade working?
A major upgrade is essentially an automatic uninstall of the existing version and reinstall of a new version. This is the least error prone update mechanism in Windows Installer. It is the recommended approach to try at first - it works well. A minor upgrade - which is upgrading the existing install, is generally more difficult to get right in the beginning. A number of technical restrictions apply. Here is a very good summary of what is required for a minor upgrade to work (as well as other details): http://www.installsite.org/pages/en/msi/updates.htm
Check out this well known wix tutorial for upgrades and patches. And MSDN.
Since I wasn't a part of my company when our build process was designed and implemented (and has been successful for quite a few years now), I found out that there were things that were being done that may be looked at as 'hacks' to MSI 'purists'. However, in order to get a workable installer with Visual Studio 2012, I've been doing the best I can to mimic what was being done with the .vdproj files in Visual Studio 2010. Of the many snags I've hit, this one seems to be the last one that I can't resolve.
As part of our build process with Visual Studio 2010, we built our code and created a Framework MSI on one VM. Then we took that Framework MSI and installed it on a different VM. After the framework had been installed, we built our product code and created a Product MSI off of it. This created a Product dependence on our Framework. What this meant was that when installing on a client machine, the bootstrapper needed to install the Framework first followed by the Product. On uninstall our documentation stated to either have it handled through ARP or by command line 'msiexec /x {Product.msi/#ProductCode}' and then the 'msiexec /x {Framework.msi/#ProductCode}'.
At the time, management determined that the ProductCode would be the easiest way for other product teams to determine if our product had been installed on a machine. This lead them to the decision that they needed to keep a static ProductCode for both the Framework and the Product.
In order to handle upgrades, they had to create a ProductTool.exe that was nothing more than the msiexec wrapped in an executable that took a /ProductCode={#ProductCode} argument.
As part of our bootstrapper, they called:
Install prerequisites (Windows Installer 4.5, .NET 3.5 SP1, SQL Server 2008 R2 Express, Sync 2.1)
ProductTool.exe (Product.msi -- to uninstall the Product.msi)
ProductTool.exe (Framework.msi -- to uninstall the Framework.msi)
Install Framework.msi
Install Product.msi
However, I didn't discover until just recently that the Burn bootstrapper does not allow REINSTALLMODE=amus. In the install logs, it says that it changes it to REINSTALLMODE=vomus. Apparently in order to get that aforementioned process to work on upgrades, they had to set REINSTALLMODE=amus.
UPDATE: I finally got to talk to the original developer of the installer and found out that REINSTALLMODE=amus was used intentionally to revert all of the versioned files (assemblies, DLL files, etc.) and non-versioned files (.config, SQL script, etc.) as a risk minimization and robustness/"self-healing" strategy.
Having said all of that, is it even possible with a standard burn bootstrap application (BA) to set REINSTALLMODE=amus so that I can get the upgrades working? The MSI files have the Property's set, but Burn seems to override it.
No, this is not supported by the Burn engine today. Burn controls the REINSTALLMODE very carefully to correctly handle upgrades and repairs. Using a in REINSTALLMODE is far from a best practice and thus is not supported. Also, it isn't clear why a is necessary in the scenario you described.
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.