I have an instance of Python 2.7.18 in my computer with Windows 10 (located in C:Python27).
Now, I want to install another instance of exactly the same Python to another location (for example, C:my_apppython27), but I have a problem with msiexec program.
I have “python-2.7.18.amd64.msi” installer from Python website, and when I launch it, it asks me whether I want to change, repair, or remove the already installed instance.
I read about different flags and settings that can be used (for example, TARGETDIR, APPDIR, INSTALLDIR, etc.), but nothing helped.
I am sure it is possible cause it is just installing a duplicate to another location.
How can I do it?
Advertisement
Answer
MSI “knows” what is installed via a number of GUIDs embedded in the installer. This design is “inherent” to MSI and is hence “by-design” not intended or adapted to multiple instances outright:
Package Code: Uniquely identifies an MSI file. This GUID should never be the same between two MSI files unless it is the same file that has been duplicated (then it is the same file of course – binary identical). If two MSI files are different and have the same package GUID they are treated by-design as the same file. This can cause some of the most mysterious problems you ever have faced. Always auto-generate this GUID (it should never have been exposed technically?).
Product Code: Identifies a unique product instance of an installed product. You can not install the same MSI over and over again with identical product GUID. You can in-place upgrade the existing installation using a minor upgrade (then product codes are identical between MSIs). This yields a single updated instance and not two side-by-side installations as you like. This is the GUID that makes your second run of that MSI show up in maintenance mode (repair, modify, uninstall) – as in “this product is already installed”. There are some complications here with package code being involved though – technicalities (you can’t easily fool it – don’t fight MSI it fights back).
Upgrade Code: Identifies a family of products. Products that are related somehow. Usually used to implement major upgrades. In other words to replace older versions already installed with a new and higher version. Should generally be stable across related releases. There are other approaches. Know what you are doing.
There are ways to deal with this. Here are some suggestions:
- I want to install an MSI twice
- Installing Multiple Instances by different msi having same Package Code
So essentially: 1) Virtualize, 2) Side-by-side install, 3) Instance Transforms. Or 4) just use a legacy non-MSI installer?
For a simple product with no registry entanglements you can simply duplicate the folder, but for a real product that is rarely the case. There are COM servers registered, GAC-involvement, file associations that conflict and numerous other problems that often lead to virtualization being the “least worst” choice.
Side-by-side installation requires a number of technical tweaks as well – most significantly changing all component GUIDs to be valid MSI – unless you use the instance transform concept (which I don’t use).
WiX has introduced the concept of “auto-guids”. These are component GUIDs that are automatically generated (for most component types) so that they can change depending on where you install on disk. Blog from Bob Arnson: Simplifying WiX component authoring.
There are also features to simplify WiX source xml.
Links: