I got a problem. I want to upgrade my app during installation process, but I run into problem with versioning. I use version number in format e.g. 5.5.789.0, some new version has version number in format 5.5.12.1. I know that installer only works with first three numbers from version so MajorUpgrade is not suitable for me. New version would not be installed in this case. Is there a way in which I can check versions in some custom action and plan upgrade from there? I cannot change the versioning as app building goes through some automatic post-processes that also works only with first three numbers and it is not possible to change that behavior.
Thanks for suggestions.
EDIT:
I am using WiX#.
It's not obvious to me why you can't use the WiX majorupgrade element. The settings would be AllowDowngrades=yes, maybe AllowSameVersionUpgrades=yes.
Using Schedule=afterInstallValidate is (as the docs say) removes the old product entirely before installing the new upgrade.
Related
I am building an installer with Wix 3.10 that will install files, create a service as well as create and populate a database.
I am using the Wix sql:SqlDatabase element to create the database and run some sql scripts to populate it during installation (based heavily on WIX database deployment, installation)
As recommended in the Wix documentation, I am testing a mock upgrade before releasing the initial installer. From what I can tell sticking to major upgrades is strongly recommended and so I am using the MajorUpgrade element as per the examples.
Unfortunately however during the major upgrade I can't seem to prevent Wix from uninstalling the database, nor can I find any guidance on how to handle this. I understand that a major upgrade is effectively an uninstall of the current version followed by a fresh install of the new version, but surely there is a way of retaining parts of the original?
I have a similar problem with the service that I install too, but based on this SO question Wix Major Upgrade: how do I prevent Windows service reinstallation? the solution appears to be to add a condition to the delete service entry of the install sequence:
<InstallExecuteSequence>
<DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>
</InstallExecuteSequence>
This implies to me that it is possible to retain entries across a major upgrade, but I may be misunderstanding.
Unfortunately there does not appear to be any equivalent installexecute sequence element for a SqlDatabase entity. Is there any guidance on how one should approach this?
UPDATE
Based on PhilDW's answer, changing the sequence or schedule of the major upgrade is done by changing the Schedule attribue:
<MajorUpgrade
DowngradeErrorMessage="A newer version of [ProductName] is already installed."
Schedule="afterInstallExecute"/>
Note however that this will only take you so far - if you plan to add support for trusted authentication as well as SQL authentication in your installer (as per the SO article above) it will not work, my assumption is that Wix determines that one component was never installed (whichever authentication option was not chosen) and therefore will always drop the database.
There are a few ways to address this, depending on the internals of your MSI:
A major upgrade that is sequenced at the "end", after InstallExecute and just before InstallFinalize, means that the upgrade is basically an install of the new product on top of the currently installed product. File overwrite rules apply, one of which is that data files won't be replaced if they have been updated after installation. So data files are saved. Other considerations are that binary file versions must be updated for those you need updating, and component rules must be followed.
If the issue is based on custom actions that run when the older product is being uninstalled, then you can use a custom action condition such as REMOVE="ALL" and not UPGRADINGPRODUCTCODE. UPGRADINGPRODUCTCODE is set in the older product as it is being uninstalled, not in the incoming upgrade.
I believe some WiX util types custom actions are based on the uninstall of the related component, so you wouldn't need that condition in 2. A major upgrade after InstallExecute increments the ref counts of each component (which is why you need to follow component rules) while following file overwrite rules. So your data file would have its ref count counted up to 2, would not be overwritten, then the older product uninstall would count it down to 1, so that the component remains, and an uninstall custom action based on component removal would not run.
If there is something you need to do in the upgrading install that's custom action based, then WIX_UPGRADE_DETECTED will tell you that you are upgrading an installed product.
On the upgrade link you refer to, Chris Painter's answer is the correct one. It's basically the same point that I'm making here, so of course he's correct :)
I have built an msi installer using WIX. And as per the requirement I have to give an upgrade for next build. So, I checked about the upgrade, types of upgrade, its implementation steps and found Major upgrade will be suitable for us. So, as per steps I changed Package code, Product code and version number (increment the version) in project main .wxs file and generate the build which is upgrading properly (for that I checked in registry, Control Panel, etc...).
Major upgrade build is migrating features properly but user has no information whether installer is upgrading or doing the fresh installation. I am expecting an message like "The setup has been upgrading from v1.0.0.0 to v2.0.0.0. Do you want to continue" as user is going for installation.
Note: In my project I am having only 2 custom dialogs else rest all dialogs (e.x. Welcome dialog, EULA dialog, InstallDir dialog, etc...) are by default coming from WixUIExtension.dll.
I explored few links & blogs related to major upgrade but I didn't got proper solution related to this. Please share your valuable comments & what is the best way / practice for this.
You can detect a major upgrade by checking the UPGRADINGPRODUCTCODE property. You would then need a custom action to query MSI for the ProductVersion of that installed product. Finally you'd have to ask the user and proceed or abort.
How do you plan on handling silent installations? Just automatically proceed or require them to pass a property such as AGREETOUPGRADE=1 ?
When you do a major upgrade, assuming you're using the WiX majorupgrade tag, then the WIX_UPGRADE_DETECTED property is set. You could use that to condition a dialog to be shown. That property value will be the ProductCode of the older product, so you'd do something like MsiGetProductInfo (ProductCode, ....INSTALLPROPERTY_VERSIONSTRING....) to get its version. The dialog will presumably need a cancel to abort the upgrade.
You may run into issues because retrieving the ProductVersion may require elevation. In general, nobody bothers to verify upgrades like this because your customers are smarter than that. They know if the install is upgrading a new product or not and the fewer questions you ask the happier they are.
We have a product that we install using WiX, and we have done some re-branding, and I would like to change some things in installation paths and file names.
So, when I make a new version of our installation, the folder with old name remains in Start menu, for example. Also, if I rename a file, the old versions are not deleted, either.
I would like to know what would be the best way of installing files with new names over previous versions of installation.
It sounds like you're doing a major upgrade with a late scheduling of RemoveExistingProducts. When you do that, you have to strictly follow the component rules. My blog post on upgrades covers ways of avoiding that, such as by using an early scheduling of RemoveExistingProducts.
I'm trying to create patches using the method from this tutorial. An issue I'm running into is that I can't install a new patch on top of a previous patch.
I can full install Version A,then patch to Version B. After that I can't patch to Version C.
I can full install Version B, then patch to Version C.
Currently we just do full installs with major updates each time which is working fine, but because of the frequency of our (internal) updates the file size and update time is becoming a burden so we're looking to reduce the update time (both downloading and installing) especially when most of the files don't change.
Edit: Another requirement is that at any given time a full install can be done instead of a patch. The solution I came up with setting a static product code made full installs on top (without manually uninstalling) doesn't work.
If you're not doing a major upgrade, but you are changing versions, you're doing a minor upgrade. To be able to install the next version .msi file over an existing installed previous version, you're going to have to set REINSTALL to a list of modified features somewhere (or to ALL if you're lazy and willing to put up with Windows Installer doing extra work). Often setting REINSTALL handled by the bootstrap, but it is possible to set it in the .msi and reset it to empty ({})when the previous versions are not installed (condition Not Installed).
Looks like the issue was that I was previously making all upgrades major upgrades, but that's not supported with patching. Changing to a static product code rather than auto-generate fixed it.
Edit:
Looks like it solved the first problem of Install A Patch B Patch C not working, but now trying to do a full install of D on top doesn't work.
I'm doing an installer, using wix v3. I have two installers. I installed my app with the first one and then I want to update it with the second installer.
I think that I'm missing something since I cannot install the product and then run an update (with other installer), If I execute the same version, I could see the maintenance windows, it recognize that the product is installed. The problem is with other versions.
I think that these could be because of the value of the Installed property. What thing should I do to have these property set correctly? I'm installing the product for all users...
What could be wrong?
See How to implement Wix installer upgrade which provides a number of detailed examples.
I have already done it. It works for the same product Id, but when I change the product Id, it recognize the upgrade code ((I'm sure of that because I set a property), but the Installed property is set as false.
I will use a property to notice the different version, something related to the last answer.
Thanks!
Did you set your WIX project to be able to detect it's an Upgrade ?
Have a look at the upgrade part of the basic WIX Tutorials