I am new to Advanced Installer, since I am using a trial version, I want as much as I can about it. I have an installer, already created.
One of the files it installs is InvoicePro.exe (version 1.0.0.0). I found some bugs in that version so I built the version 1.0.0.1 in Visual Studio. Now I want to create a Hot-fix installer to replace version 1.0.0.0 with version 1.0.0.1.
Please explain me clearly!
The upgrades page from our user guide explains what you need to do. Just make sure you increase the version number for one of the 3 fields, otherwise Windows will not remove the old version, because it ignores changes in the forth field of the product version.
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.
I have a Visual studio 2010 project A and a setup project SetupProject.
I would like to have a solution of patching/upgrading the installation on one machine by updating several dll, namely a.dll (primary output of A) and b.dll (some other dlls that A depends on).
Following this patching guide using Orca and msimsp, I am able to create a patch solution for my installer.
The problem is msimsp needs a target for comparing with the newer installer, meaning I have to say specifically "this is a patch from 1.0.1 to 1.0.2" and this patch requires that the current installed version is 1.0.1. I cannot use that for patching a 1.0.0 installation.
In other words, the patches have to be applied in sequence, one after another.
My question are :
How can I use Patch_101_To_102 to upgrade any version 1.0.x to a 1.0.2 installation, without the need to go through 1.0.1 patch ?
Would you suggest another solution other than this patching solution ? The problem with this solution is that it calculates the delta difference between two version, so I think that's why it requires the patches to be applied sequentially. It would be great to have a solution saying "overwrite these specific dlls only"
Strictly speaking Visual Stusio suports only the RemovePreviousVersions upgrade, so most people in your position might choose another tool that has a bit more support for patching.
Anyway, why are you creating a patch for 1.0.1 to 1.0.2? Most people build an accumulating patch. Just keep the 1.0.0 build around for as long as you need it, and build all your patches against an MSI that keeps accumulating fixes. Youd increment your MSI version, create a new patch guid, and in the PCP file say that this new patch superseded the previous ones, in ListOfPatchGUIDsToReplace.
My WiX installer (Wix 3.10, MSI 4.5) uses MajorUpgrade for updating. The files to be installed are harvested with heat.exe in pre-build. The current (older) msi file contains a file nlog.dll (which came with a NuGet package v4.1.0) that has a file version of 4.1.0.0, a product version of 4.1.0 and last write time of 2015-09-01.
Since the nlog team ran into some strong naming issues, they published an updated NuGet package v4.1.1, containing an updated nlog.dll with its file version decreased back to 4.0.0.0 while its product version has been increased to 4.1.1, last write time is 2015-09-14.
Now I'm running into a related issue as Robbie did here: wix major upgrade not installing all files: When I install the new msi package and the major upgrade is performed, the present nlog.dll (which is newer according to its file version, but older according to its file date and product version) is being removed, but the new nlog.dll isn't installed.
However, using Schedule="afterInstallExecute" or Schedule="afterInstallFinalize" as suggested won't do the trick for me. Instead of removing the newer file and not installing the older one as in Robbie's case, it doesn't overwrite the present file, and just leaves it in place.
Long story short, I would like my installer to simply install all files that come with it, regardless of any file/product/assembly versioning stuff. There are valid circumstances in which replacing a newer file with an older one is desired. Can't you just tell the installer engine to ignore file versions/dates? If not, what are my options?
You can set the REINSTALLMODE property to AMUS instead of OMUS. This will affect all components globally.
The other trick is to use "version lying". This is where you author the file element with a higher version. Using heat can make this difficult as now you have to transform the XML before compiling it.
Of course the real solution is to hit the nlog team over the head. But based on what I've seen from them over the years it'll never happen. Perhaps you just use a resource editor to hack the DLL and 'fix' the version #. That's assuming you don't need it strong named. This feels dirty and a possible CM nightmare to me though.
Or just dump nlog. :)
If this is a major upgrade and you want everything to be uninstalled before the new product is installed, then you schedule RemoveExistingProducts after InstallInitialize or InstallValidate. That does the uninstall first.
I can't tell if you're getting the "disallowing install..." issue or not, but if you are, and there are other clients of the Dll (it's shared with other installed products) then I'd see if that Dll has support for private copies so you can have you own private copy for your product. If it is shared with other products I wouldn't use version lying - I'd open the Dll with Visual Studio "open as file" and change the version! Make that your latest shared version, so every package that installs it can just use it.
If it's not shared with other products and you're just running into that MSI quirk, then make your own upgrade element and schedule RemoveExistingProducts before CostInitialize, which is what is deciding not to install. That works, but it's before MigrateFeatureStates so you will lose feature migration in your major upgrade.
I have my application set up to only allow one install. If the application is already installed wix nicely pops up with this message
Is there a way to give the user the option to uninstall the application at this time? I don't want my users to then have to go to menu -> app -> uninstall or control panel. I would like to make it easy for them to remove the old version and install the new one.
That message is a feature of Windows Installer - it's just the way everything works, based on the fact that the product's ProductCode and PackageCode are present on the system. Since that message comes from Windows (not WiX) there is no tailoring it to install the MSI file that prompted it.
You can't have the same ProductCode installed more than once per-system install, so an option to install another MSI with the same ProductCode doesn't exist unless you make it a minor update by installing an updated version of the MSI file with an update command line.
The way you make it easy to upgrade is to use the WiX MajorUpgrade tag. You also need to increment ProductVersion in the first 3 fields, have a new ProductCode, keep the same UpgradeCode, and decide where you want the upgrade sequenced, and that depends on whether you increment file versions for updated files, and preserve component IDs for the same resources. This installs the new product while uninstalling the older one. This standard automatic major upgrade doesn't say "do you want to upgrade to this new product?". It just does it, the assumption being that people are in fact pretty smart and they are well aware that they have a new version of an installed product and that this will upgrade it. The upgrade is also a fresh install for people who don't have any old versions installed.
I migrated a Visual Studio Setup Project to WiX.
If I upgrade the Software installed by WiX with a WiX Setup (increased Minor Version), it upgrades fine.
But If I try to upgrade the Software installed by VS Setup, with my new WiX Setup, it does not remove the old Installation. And I kept the same Upgrade Id.
Is this not possible?
What does it do? You get two entries in Programs and Features after you try to do the upgrade?
If the upgrade codes are identical, and the product codes are different, and the new one has a higher version, the most common reason is that the older install is per user and the upgrade is per system (or the other way around). In VS setups that's the "Just me" setting, and it might be the default.
But yes, it is possible. It's nothing to do with the tool you use to build the MSI file, it's a feature of MSI files and Windows Installer.