My company uses Wix Toolset to create an installation package for one of our applications. As part of an upgrade, we changed the names of some executables and dlls.
When I attempt to install the new version on a machine with the old version (something that had worked flawlessly beforehand), everything works fine until the very end of the installation, when all of the files in the installation directory are unceremoniously deleted.
What setting is causing this? If this has happened to you, what dumb thing did you do to cause it and what restored balance to the world?
Thanks.
Related
We have developed an application that is distributed through Windows Installer, created with the use of WiX, where our customers can upgrade from any older version to the newest.
Our latest version however, deletes 2 dll's, and this is only rectified through a reinstall.
Details on the NuGet packages
Microsoft.IdentityModel.Protocol.Extensions was upgraded from Nuget Version 1.0.2.206221351 and File version 1.0.20622.1351 to Nuget version 1.0.4.403061554 and File version 1.0.4.54.
Similar changes happened to file versioning of System.IdentityModel.Tokens.Jwt from Nuget version 4.0.2.206221351 to Nuget version 4.0.4.403061554.
So by changing how the File version was calculated, MS effectively changed the version to a downgrade of the previous (from 20622 to 4 on the build version).
Why the dll's are removed on upgrade
Some call it a bug, and some call it a feature, but what happens, is that the MSI has a step where it records all the files that needs to be upgraded, it then uninstalls the current version, and then only installs the files that was unchanged or bumped in version - any downgrades are left out.
Question: How do we get around it?
We are shipping this product to a lot of different customers, with very varied technical skills, so an upgrade better work, or we will be flooded with support issues. Are there anything I can change, without actually disabling features like the ability for the MSI to rollback in case of errors, which I have seen as a trade off for others solving the same issue.
You have a few options. One is to change where you schedule RemoveExistingProducts. Another is to use REINSTALLMODE=AMUS instead of the default OMUS. Another is to do version lying on the offending DLLs so that they always get reinstalled. (Author the file element so the version is 65535.0.0.0 or something like that.)
It's an MSI feature... the bug is in Nuget releasing a newer DLL with a lower version #. That breaks MSI's component rules and default file versioning rules.
This might help:
https://blogs.msdn.microsoft.com/astebner/2015/11/16/why-windows-installer-removes-files-during-a-major-upgrade-if-they-go-backwards-in-version-numbers/
and basically Chris is correct, and:
The RemoveExistingProducts placement should be before the costing actions which cause the error.
Another alternative is to open the files with Visual Studio and alter the file versions in the resources so that the rules are followed. File version would not affect assembly version. Just run Visual Studio, then File-Open File, and the Resources section will show where you can change the version.
It's also very likely that a repair will restore the missing files because the missing files "break" the product install. That's easy to test. If that is really the case, then it will repair automatically (and just once) if the app starts with a shortcut, or you can arrange for the shortcut to be advertised. If not, I've seen people use MsiProvideComponent () to make sure the files exist because that will do the repair/install.
So we have MSI that installs a patch consisting of two files and a registry entyry. It works fine on the initial installation, however if you try to reinstall it, it will not replace the files that it should. Is there a way I can have WiX force the MSI go to into reinstall mode rather than repair mode (I think that is what it is entering)?
Edit:
Was asked to clarify the usecase, so here's a copy of the comment I left below.
So the usecase here is that a client has all the software installed, including this patch. Something doesn't work so they uninstall everything and then try to reinstall the software. When they do so this patch (msi) will not reinstall. It will see that it is already installed, and enter repair mode. From there it will see that the files exist, not caring that the files are older, and will not update them. We need those files updated whether the patch thinks it is currently installed or not.
It might help if you said exactly what's happening that makes this an issue.
When you install a patch, the files (and so on) are replaced, and now the patch is part of the product, not a separate thing that can be re-applied. Going into repair mode when trying to re-apply should be fine because the repair will be based on the initial product plus the patch, so any files that need repair will be repaired. You can't install the same patch twice any more than you can install the same MSI file twice - it's already installed! Hence my question about what you're seeing that is an issue. Is it not repairing correctly?
After seeing your edit, a patch is an msp file, not an MSI file. In order to uninstall everything both MSI products need to be uninstalled, not just the first one.
I am working in wix installs.
I am facing some problem while upgrading wix installs from one version to another version. My scenario like below.
I have installed my product x.1 and it have sample folder in install folder but I want copy my sample folder files into backup while upgrading my installs.
But my problem is files are removing in upgrade before creating backup.
Please any one help.
Advance thanks
Uma
There's nothing built in to backup files, but this is the gernal approach to do that:
http://blogs.msdn.com/b/astebner/archive/2008/10/19/9006538.aspx
A thought: why do you need to do that? A major upgrade is a full install of an entire product (not simply the files you want to update) and it happens to uninstall an older version if there is one, so just include the sample files in the new setup.
Some people are having trouble installing my AIR app. Most are installing it fine.
Some of the people having trouble are installing it for the first time, others as an update.
I've tried two versions of the installer - one with a migrated cert, the other without migration.
Also, I've gone through these steps with them:
check that your computer's system clock is correct. Correct the date and time if it not current.
make sure you have the latest updates for your machine eg latest Windows updates for Windows machines
install the latest version of the Adobe AIR runtime (download from http://get.adobe.com/air)
uninstall my app if it is already installed
make sure the application folder does not exist (in, for example, c:\Program Files or c:\Program Files (x86)). If it does exist, delete it.
empty the Trash (Mac OS) or Recycle Bin (Windows)
try installing my app again
I'm wondering if there are any other steps that you are aware of to test?
Cheers
i have already an installer for our application. but it is exe-file. it was created many years ago.. application of course was updated. we used a bat-file to register new dll-files and to install our service(windows). but we want to do all this by installer not a bat-file. we chosen a wix techology. i read about <Patch> node, but to use it i need an msi from previous version.. i think to do a simple installer, that will stop service,copy and register dll in the installed application's directory, install service. but i don't know will it overwrite the files without any problems?
You can only create an MSP (Patch) for an MSI (Installer). Also, you're going to run into component ref counting problems if you install your components into the same directory as the original install. The problem is MSI will go to see a file is already there, make it as a shared resource and increment the usage counters. Then on uninstall it will decrement, see that it's not 0 and remove to uninstall the files.
I'd suggest installing to a new directory and then using the RemoveFile table to get rid of the old files. Also I'd suggest following good CM / Versioning practices so that you don't have to worry about hacks such as Version Lying.
If all your application just needs to xcopy files, setup a directory and maybe even a ShortCut, it should be a piece of cake.
Versioned files like executables will automatically be overwritten if the version of the file number is lower.
See also Copy if not exist in WiX.