During upgrade, I can use to determine ProductId that installed on the machine.
Is there a way to know the version, like 1.0.0.0, in addition without handling that by yourself, storing in registry etc.
I think you are looking for Upgrade Version element. Using this element you can specify things like range of versions for which upgrades are allowed or range of versions for which upgrades are not allowed.
You can also read through this post for a detailed explanation of how upgrade works.
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).
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.
We have an installer that consumes a merge module. The newest version of the merge module includes downgrades to some files. When using the installer to upgrade from an earlier version we are having problems downgrading these files.
Initially the files from the merge module were being removed and not re-installed, but after reading wix major upgrade not installing all files I set Schedule='afterInstallFinalize' on the MajorUpgrade element. This resulted in the files with the newer versions being retained.
How can we change either our installer or the merge module so that these files are downgraded during an upgrade?
Well, in my opinion, the best way to approach this issue is to sequence the standard action "RemoveExistingProducts" to before CostInitialize standard action.
Be aware that this scheduling is not in accordance with the Microsoft recommendation at :
https://msdn.microsoft.com/en-us/library/windows/desktop/aa371197(v=vs.85).aspx
So, when you try to build your msi package, you might have to end up suppressing ICE error messages ,which if not suppressed, might prevent you from building.
There is an easy way to suppress ICE error messages in Wix . You can do that in the Visual studio IDE as well as when using the candle.exe to compile your .wxs project. The Wix documentation will give you enough details about this.
If you are wondering if its ok to go against the Microsoft recommended placement for RemoveExistingProducts, take a look at :
Downgrade File in MajorUpgrade
FWIW, I've talked to MS support in the past about having REP before costing to make upgrades work successfully, and at that time they said it was ok, while pointing out that it's also before MigrateExistingFeatures so if you migrate features during upgrades there'll be an issue.
What this means is that , if you have multiple features in your msi package and you want the exact same set of features to be upgraded by your upgrade package, then this approach might not work.
However, if you just have a single feature in your msi package, then this approach will work.
Also, be aware that placing RemoveExistingProducts outside of InstallInitialize and InstallFinalize has other consequences, in case there is an error during your upgrade, as RemoveExistingProducts is not transacted.
What might happen is that , RemoveExistingProducts will uninstall your old application and then the upgrade process starts the installation of your newer version of your product. However, at this point of time, if there happens to be an error installing your newer version of your product, then the upgrade rolls back and then you will be left with no version of the product on your system.
http://blogs.msdn.com/b/heaths/archive/2010/04/09/major-upgrades-with-shared-components.aspx
-The other option is to make use of REINSTALLMODE property.
You will author this property in your property table with a value of emus
REINSTALLMODE = emus.
If emus doesnt work, try with amus.
using amus is fraught with risks and should be avoided for the most part, except in exceptional circumstances.
https://msdn.microsoft.com/en-us/library/aa371182(v=vs.85).aspx
However, exercise caution here again.
REINSTALLMODE are caller properties and are usually set by the person performing the installation and hence its not a good practice to author this in the Property table.
However, there might be exceptional situations such as yours which might require you to take this approach.
-The other option i was thinking was to change the component GUIDs of the components in your Merge module.
However doing so would only work if the following condition is met:
-All the consumers of your merge module have RemoveExistingProducts sequenced very early in the upgrade cycle i.e they follow a method of ugprade where the older product is uninstalled and a newer product is installed.
So this might lead to re-sequencing of RemoveExistingProducts in all of your consumers.
Reason being, assume for a moment that you change the component GUID in the present version of the merge module and then you rebuild the latest version of the installer using this merge module. If RemoveExistingProducts is sequenced later in the upgrade cycle i.e after InstallFinalize, then it's a violation of windows installer component rules. You have two products installing the same file to the same location but with different component GUId's. Hence, its absolutely critical that if this approach is followed, RemoveExistingProducts is sequenced very early in the upgrade cycle.
Hope this helps.
I would like to distribute an application that depends on several PyPI-packaged libraries. I have carefully selected certain versions of some of these libraries as newer versions (in some cases) are incompatible. My installer downloads them (with pip) at install-time and sets up the environment for the application. But how long are those versions going to be available? 6 hours? 2 years? Anything in between?
I'm basically looking for some sort of policy that tells me how long those versions of libraries are going to be hosted on PyPI (and who makes that decision).
In-before-"distribute them yourself": That is an answer to a different question.
This is really about how PyPI works, not how I distribute my application.
The friendly people in #python tell me that authors can delete any version of their packages at any time.
The only way to indemnify yourself against a version of something becoming nuked is to (assuming their license allows it) ship it yourself.
There is an argument for continuous integration against the latest versions on PyPI but that does assume there will be a new version and that the author doesn't just delete the whole thing. CI is just a good practice here, not a panacea.
I have created a Installer for my product in WIX.
The requirement was that, user should be able to install two different versions of the product on their machine.
I have modified the Upgrade code for another version, so that previous version does not gets uninstalled when the newer one is installed.
I have also changed the names of the shortcuts that are created on Desktop and in Start menu.
Now my question is that whether I need to change the Product Code also?
Do I need to
Yes, you also need to change the ProductCode.
The correct approach for supporting side by side installations is to use the same UpgradeCode for all versions. After that you can remove the upgrade rule which prevents downgrades and modify the rule which automatically uninstalls older versions.
As a side note, each version should use a unique install path.