Installing Multiple Instances by different msi having same Package Code

Old Classic: Virtualize, seriously.

Package Code: A package code must be unique per MSI file.

"I want to install multiple instances of a software. I have multiple msi of different versions. However, the Package Code of those msi are the same."

This is an error. A package code is a unique identifier for an MSI file. If two MSI files have the same package code they are by definition the same file as far as Windows Installer is concerned - very strange problems can result - if the files are indeed different (and not just copies of the same file).

Perhaps you are referring to different product codes. This is indeed possible, and can indicate different versions of the same product (different version, different language, different edition, etc...). In such cases they generally share the same upgrade code - which is a code that identifies a family of related products.

Summary:

• Package Code: identifies a specific MSI file.
• Product Code: identifies a product version.
• Upgrade Code: identifies a family of related products.

Multiple MSI Installation Instances: Windows Installer is sort of ill-equipped to handle installation of the same product multiple times. The whole paradigm sort of assumes a single installation instance - centering around the component rules and their reference counting based on a single, absolute installation path as explained in this answer. There are some built-in constructs such as "instance transforms", but for me they seem like "afterthoughts" that are added to support something that requires a whole lot more design changes to really work. The whole application must often be changed to be able to co-exist in different versions peacefully.

Legacy Setup.exe: Sometimes people resort to legacy setup.exe installers to easily support multi-user installations. NSIS, Inno, Installshield legacy projects, etc... Not ideal, but it does offer relatively easy multi-installations.

Pros & Cons: Just a quick reminder about MSI's best features, as well as common problems and some design challenges (towards bottom).

Virtualization: Virtualization might be the easiest way to achieve what you need? Either running the different application versions in different virtual machines, or using virtualized packages - such as Microsoft App-V (application streaming - JIT delivery - no local installation per-se, can run incompatible software side-by-side, updating through server, licensing benefits?). The conflicts between the application versions are then "sandboxed". Not my favorite concept, I have to say, but it works for many and is in real-world use many places.

MSIX: Maybe consider having a quick read about MSIX - a new universal package format designed for Windows 10 apps. "Containers".

Instance Transforms: The built-in MSI concept for this is multi-instance transforms. Please investigate the MSINEWINSTANCE property and read up on the MSI SDK topic: "Installing Multiple Instances of Products and Patches". And here is perhaps a better example - more practically oriented. I avoid this concept altogether. I believe it can work though - with some planning and application changes. Why do I not use instance transforms? There are some issue - as described by Carolyn Napier here (unsure whether this particular issue has been resolved by now). Overall I find the concept not appealing - if I need side-by-side MSIs I will implement that myself "manually" - "the elbow-grease-way" (see below).

And now, the two cents from a (natural-born) Virtualizer.

Trolling From The Past: I have written on the topic of multi-instance installations before: I want to install an MSI twice (from serverfault.com - site for system administrators).

Side-By-Side MSI Setup By-Design: It is possible to make your MSI setups so they always install side-by-side - without using instance transforms. Essentially you do all the side-by-side preparation yourself making setups that do not interfere with each other. This generally requires major design changes to the application and discipline from the product managers to a degree that is rarely seen. COM servers must generally be manifest based with no registry involvement. File associations must not be shared. Shared files must be fully version compatible or installed as side-by-side assemblies. MSI component GUIDs must be auto-generated (WiX has features for this: auto component GUIDs) and the installation directory must be unique per version - perhaps just by including the version number in the installation path. You need different upgrade codes for each side-by-side stream or branch. Etc... The list goes on. Another alternative is to put shared components in a separate MSI which is installed as a pre-requisite and maintained with its own release cycle. Compatibility problems are possible. Obviously. Side-by-side assemblies may work, but they are not without vulnerabilities either (publisher policy files can be accidentally removed - breaking redirection en-masse). A lot of foresight and elbow grease needed, but benefits can definitely result. For example the successful side-by-side installations of a UAT and a PROD version for a product.

Some Links:

• Disable repair mode and upgrades in wix installer
• How to create windows installer
• wix generating new upgrade code
• How to solve self-repair conflicts from side-by-side installations? (section 5)
• How to prevent Wix from installing an older version? (challenges for side-by-side MSIs without using instance transforms)
• Automatic way to update component code in InstallShield Basic MSI project (on instance transforms)