Is there any reason not to set up the install so that major upgrade is always done and productcode changed?
I find that supporting different kinds of installs needs more code, and "repair" install seems to work easier with major upgrade. Also the application that needs to be installed is not very big, thus there is no need for "service packs" or patch installers.
No. If you application is small and you don't feel the pain of uninstall and install then Major Upgrades are the easiest thing to do.
I'd only move to the more advanced update mechanisms if the Major Upgrade user experience was unacceptable.
I generally find that minor upgrades are only useful in a few cases:
1: Uninstall Bug: There is a bug in the uninstall sequence of the installed MSI. Since a minor upgrade does not uninstall the product, but merely reinstalls it. This allows you to fix whatever was wrong in the uninstall sequence before it is called.
2: Hotfix: There is a very small tweak required for a very large product. Say a bug fix for a single file or a few files. There will generally be a small bug requirement after a couple of weeks for all large products where you need to replace just a few files. Major upgrades can be terrible for this - uninstall and reinstall for just 4 out of 10000 files?
3: Patching: You want to deploy a patch for your product. MSI does allow major upgrade patches, but these are even more complex to get working than minor upgrade patches (which are also difficult).
The "Small Update" feature should never be used for any purpose in my opinion. Major or Minor upgrades only.
Update type Change product version? Change product ID?
Major upgrade Yes Yes
Minor upgrade Yes No
Small update No No
Related
I have a product and the version is 1.3.9. It has a severe bug when uninstall it. I fix the bug and make the product 1.4.0. Then I want to overwrite the 1.3.9 version whitout unintall it. Is there anyway to do that?
Minor Upgrade: Yes, you need a minor upgrade. It upgrades the product in-place and does not trigger uninstall. After that is done you can run the uninstall - now with a corrected uninstall sequence - and you can use major upgrades again the normal way - but you need to migrate yourself out of trouble with a minor upgrade. Minor upgrades have many limitations.
Note: it is also a problem that when your next version comes along you need to provide a minor upgrade again to migrate users who are still at the problem version. There are various approaches here - such as using the same minor upgrade wrapped in a setup.exe launcher.
Clunky Version: You can also make the new version ask for the user to manually uninstall the previous version. Not a good solution, but possible. Then you avoid the need to have to deliver a migratory minor upgrade as part of future launchers?
Maintanence of minor upgrades for broken major upgrade fixing (Michael Urman of Installshield)
Various Fixes: There are many hacks and tools you can use to clean this problem out, none are ideal (do visit that link).
We have two installers build in WIX with the constraint that Product code has to remain same. On doing an upgarde from old to new, I get an error, "The specifile account already exists."
Does WIX allow any workaround for me to achieve an upgrade while keeping my product code unchanged.
It depends what you mean by "upgrade" but there is no such thing as a major upgrade where the ProductCode stays the same. Keeping it the same is not a constraint, it's against what a major upgrade does. You should say why you believe it's a constraint to keep it the same, and if you decided it's a solution to a problem you haven't told us about.
The error message is from a WiX util CreateUser custom action of some kind. You haven't specified what you have changed in your MSI file, but if you are just running your new MSI and it's got the same ProductCode then you are probably doing a repair, and that repair is running the CreateUser again and telling you it already exists. You should supply more info about your CreateUser.
You'll also need to say what kind of upgrade you are doing (major, minor?) and if it's minor then what is your command line?
Minor Upgrade: That is just a minor upgrade - a different form of MSI update from the more commonly used major upgrade. Info about Patching & Upgrades (in general).
Complex & Limited: There are a number of restrictions for minor upgrades that make most people end up using major upgrades. Essentially a minor upgrade can add new features and components, but cannot reorganize the feature-component tree. But wait, there are many more restrictions:
Minor upgrades can not change the MSI file name, it must match the previously installed version. I always end up banging my head against this one having forgotten the restriction, hence this specific mention.
Some further limitations as capably explained by Flexera's help file: Major Upgrade vs. Minor Upgrade vs. Small Update (third column).
Aging, but good content from installsite.org on the same topic: Windows Installer Updates and Patches.
MSDN description of limitations: Changing the Product Code
Advanced Installer's Creating Patches list of limitations and restrictions (applies to minor upgrades in general as well as minor upgrades delivered as patches).
Installing Minor Upgrades: A minor upgrade can be delivered as a regular MSI or as a patch file. The standard command line used to install a regular MSI file:
msiexec.exe /i MySetup.msi REINSTALLMODE=vomus REINSTALL=ALL
Maybe see this Flexera help file page for some more details on installing minor upgrades (some Flexera-specific stuff, but mostly generic). That is where the above command line is from.
Personal Opinion: Let me end with a subjective observation. I find minor upgrades excruciating for real-world use, and I have only successfully used them for "hotfixing" (just update a couple of files with no other changes), and to fix errors in installed product's uninstall sequences which prevented them from successfully uninstalling. In these cases the minor upgrades became so simple that they worked reliably. In order to deliver a real-world product with only minor upgrades, a lot of care, foresight and discipline is needed (not to mention a patient and insightful product manager who will understand these technology limitations and what they mean for real product deployment).
With all that said, let us not underestimate the huge, corporate benefits of MSI (beyond mere upgrading issues and related details):
The Major Benefits of MSI (compressed - "executive summary")
The Corporate Benefits of Using MSI Files (elaborate and verbose)
I had an MSI with a CA type 1. Later on, I realized that CA had to be changed so I updated it and created an MSP.
Q1: If I install the MSI and then apply the MSP, I don't think the cached MSI (one in Windows\Install directory) contain the updated CA, right?
Q2: If I uninstall this MSI, does the installer uninstall the MSP first and then the MSI?
Q3: Which CA would be performed during uninstallation? An updated CA or the original CA? Or an updated CA first and then the original CA?
Thanks in advance.
In (typically) the \windows\installer directory there is the cached MSI and any patches that have been installed for that product. When some installation action is performed the cached MSI and all its related patches are "merged" to create the view of the actual currently installed patched product, so:
So Q1 doesn't really apply because nothing is done with the cached MSI on its own. If you look at it with Orca it won't reflect the patch, because that's in a separate MSP file.
Q2: There is no first and last because the (MSI+Patches) is what is uninstalled, followed by clean up removing the files that are no longer needed.
Q3: There is only one CA in (MSI+Patches) and that's what is called.
PhilDW has attended to your specific questions, maybe I can make a few guesses as to what the underlying problem really is.
Is this a minor or major upgrade MSP? A minor upgrade patch can be used to "hotfix" errors in the installed MSI's uninstall sequence - if that is what you are really asking. I have done so many times, and when you install the patch first and then uninstall, what is running on uninstall is what you included in your MSP - the new CA - provided you installed everything correctly (command line, etc...). The MSP is merged to the cached MSI - as Phil states - at runtime. What I am a little fuzzy on, is how any applied transforms are handled - this is something I have never had the time to test. Are you using transforms?
This approach is frequently used when you discover an error in the installed setup's uninstall sequence which prevents a major upgrade from running correctly. In a regular major upgrade the old custom action may or may not run from the old setup depending on how it is conditioned (see link for some conditioning cheat sheets), but typically it either runs undesirably, returns an unexpected error that triggers an undesirable rollback or the whole custom action crashes, causing a failed major upgrade (or failed uninstall).
The above yields a catch 22 situation where your existing install appears un-uninstallable and un-upgradeable - but a minor upgrade can come to the rescue (a regular MSI installed as a minor upgrade should also work - it shouldn't need to be delivered as a patch, provided that you properly re-cache the new MSI from the command line - a patch is merely a distribution mechanism for an upgrade that is already working).
A major upgrade patch (MSP), on the other hand, will not allow you to fix errors in the uninstall sequence of the existing installation since it triggers the uninstall sequence of the pre-existing install and just tells it: "uninstall yourself" - as part of the major upgrade operation. When this happens, then the old CA is used - which is embedded in the cached MSI for the old setup. It is the old setup running - unchanged.
It has been over a decade since I made a major upgrade patch - I find them pretty bad and I avoid them if possible. There are too many problems - and honestly: a few serious logical flaws (for example the fact that the product you are trying to patch may already have been uninstalled - if you schedule RemoveExistingProducts early - see below - a rather ridiculous error, one would have to say). I have never made a major upgrade patch using WiX, but I tried with Installshield and briefly with Wise. In order for them to run at all, you have to set the uninstall of the old version to happen after the install of the new version (so the old version isn't already gone by the time you try to patch). This means RemoveExistingProducts must be late in the InstallExecuteSequence - which makes the setups vulnerable to component referencing errors (another common problem).
UPDATE: I should also add that my major upgrade test - done many, many years ago - also had problems with feature state migration (MigrateFeatureStates) - the patch caused all features to show up in an unknown state. To this date I have never had the time to figure out exactly what happened, but I think it may have been my own doing. I did something funky with the Preselected property (I think it may have been related to a merge module doing something stupid - and I tried to "fix" it - with another fix that didn't fix anything, but caused new problems - and such forth and whatnot :-) - deployment is fun). Just reporting the failure, and whatever intel I have - not claiming to have any solutions. There were also other problems - but most of them were Installshield specific I think. WiX might do a lot better. Wise was sensationally good for minor upgrades (they really did work), but I never used Wise for a real major upgrade.
A typical major upgrade custom action problem is that the custom action is erroneously conditioned and will run in both the old version's uninstall, and the new version's install. There are many modes to test your conditions in, and you will be surprised if you take the time to do so: install, repair, modify, uninstall, patch, etc... And you will often find that the custom action runs unexpectedly on modify or repair operations or similar. I linked to a couple of cheat sheets for conditions above, here it is again: Is it possible to run a custom action only in repair mode.
UPDATE: And a common patch problem is that custom actions may run unexpectedly because they are not conditioned with NOT PATCH. Rant: I wish patching would be its own thing in MSI and not just a delivery mechanism for a regular update, and that it would target files only and have its own installation sequence (like admin install has). This would allow "targeted patching" and small hotfixes for huge products - which really need some working, down-to-earth patching that is not overambitious and over-complicated (which is what patching in MSI currently is - in all honesty).
Advice? Use a minor upgrade patch or a regular minor upgrade (not delivered as a patch) to fix the uninstall problem, and then proceed to use your normal upgrade approach. It should be possible to deliver all this in a WiX Burn bundle - but I have never had time to test it.
My 2 cents? Forget patching if your product is small, and just use a regular minor upgrade MSI. If your product is huge, then use a patch package (or your download bundle will be a lot larger than necessary). Be aware that your future setup bundles should also contain the "hotfix" patch / MSI to allow users with older installations to fix the uninstall error before installing the latest version. A little clunky, but it should be manageable. If your old setup has a working uninstall, but fails as a major upgrade (because of an insignificant error in the uninstall sequence making the whole process fall over), you can uninstall the old setup with a regular uninstall command passed to msiexec.exe and then install the new version afterwards (avoiding the major upgrade scenario by performing a manual uninstall first). I haven't tested this with Burn yet.
I have a bootstrapper application with several msi packages in the chain. For convenience, the msi packages always perform a major upgrade that completely removes a product before the new version is installed.
When a rollback is necessary during an upgrade operation in the middle of the bundle's chain, the previously performed major upgrades are reverted resulting in the affected products not being installed any more.
This seems reasonable but is probably not what the end user expects. Instead of some products being left uninstalled, those products should be ideally reverted to their previously installed versions.
I wonder if their is a way to solve this requirement without giving up the major upgrade strategy. Can a WiX bootstrapper rollback major upgrades in a way the end user expects?
I had the same question and opened a support ticket with FireGiant. Their response was:
Unfortunately, Burn doesn't do that today. Bundles only carry "their" packages, not older ones. And bundle version N could upgrade version N-1 or N-10 so it wouldn't be feasible to repair one package. Instead, the current best advice is to tell the user to run repair on the already-installed bundle. There's an open feature request to have an option to tell Burn to do that automatically but it hasn't been implemented.
I have a reasonably large WiX installer (250 Mb plus) and I am trying to come up with a suitable upgrade strategy.
Most of the files in the installer will not change and we would prefer not to have to distribute the whole package when only one or two files have changed.
I have looked into major and minor upgrades and my understanding is that a major upgrade will happen if the Product ID changes, so long as the Upgrade ID stays the same and minor upgrade patches can be used if both of these values stay the same.
My feeling is that a minor upgrade using a patch would be the best option to handle the cases where only a few files change and only to rebuild the whole installer when a substantial number of files change.
I have tested this using "torch" to produce a "wixmst" file based on the differences between two "wixpdb" files, then building a patch from that. However, I found that I can only patch from one version to another (e.g. 1.0.0 to 1.0.1, then 1.0.1 to 1.0.2 but not 1.0.0 to 1.0.2). Is it possible to target a minimum version for a patch and support any version above it?
Patching is a pain so get ready for a lot of it as you learn to master it. Here's another strategy that might work for you. Split your MSI out into 2 MSI ( Microsoft calls this Micropackages ). Have a Base MSI that contains the bulk of your content that is expected to not change and a Second MSI that is much smaller that contains your files you expect to be high churn.
Then use Burn is a bootstrapper to handle chaining these together and uninstalling them together. This is similar to what Visual Studio does.
Now you can just ship major upgrades of your second MSI.
I believe that it is possible to patch in the scenario you described above, as long as the patches are uninstallable. An example scenario would be:
Install msi (v1.0)
Install msp (v1.0 - v1.1)
Uninstall msp (back to v1.0) then install msp (v1.0 - v1.2)
For more information on uninstallable patches, see the wix documentation: http://wix.sourceforge.net/manual-wix3/patch_restrictions.htm
and the Windows documentation: http://msdn.microsoft.com/en-us/library/aa372102.aspx.
Note that to create uninstallable patches there are certain restrictions and you must be at WiX 3.0 or greater.
Like Christopher mentioned, patching can be a pain. I have found that in many cases, my managers may ask for the ability to do patch upgrades when all they really mean is for the user to be able to upgrade without manually installing first, which can be accomplished by a major upgrade just fine.
That said, if you have customers that require many small updates that get downloaded frequently, then patching may be worth the extra effort.
While Christophers answer is awesome in that he suggests the wix bootstrapper, I would discourage the route of doing major updates for the "high-churn" package. The problem is that after you have done your bootstrapping patch which internally does a major upgrade of your volatile libs in the HighChurn.msi from version v1.0 to v1.1, the bootstrapper will not, to my knowledge, re-install the previous package of HighChurn.msi in v1.0.
There's another path: you can certainly author patches which target the release of your main package. Given what you wrote I'm not entirely sure, but if your 1.2 patch can only be applied to 1.1, then you probably diffed your 1.2 only against 1.1, and not against 1.0.
Here's a neat guide how to create patches: https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/patchwork/
Follow that guide, do superseding patches ([PatchFamily/#Supersede], it'll make v1.2 invalidate everything which v1.1 shipped, so you are basically forced to make v1.2 patch v1.0 and not v1.1), and add this flag to the patch element to target the major release, even though higher versions are present: Patch/#MinorUpdateTargetRTM="yes". Always diff your patches against the release installer (HighChurn.msi v1.0), never against the installer you used for a patch (HighChurn.msi v1.1).
There are of course situations where you might want to require a certain upgrade installed for patches: A well planned fixpack/servicepack scheme, for example, where patch 1.1.1 requires service pack 1.1 installed on top of the release 1.0.
A final word on patching your volatile data (I'm presuming versioned libraries here): You might want to have an eye on which libs you could basically replace in the patch. Then you can create patches with very few data, by only giving the changed libraries a higher version. If you increase the version on all of your libraries, all libraries are going to be patched, resulting in larger patches. This might require a slightly more complicated build workflow (God knows it did for us).