通过具有相同程序包代码的不同msi安装多个实例 [英] Installing Multiple Instances by different msi having same Package Code
问题描述
我想安装一个软件的多个实例.我有多个不同版本的MSI.但是，那些msi的Package Code是相同的.我要安装第二个实例时，弹出错误消息已经安装了该产品的另一个版本."
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. Error "Another version of this product is already installed" pops up when I wana install the second instance.
我可以使用msiexec命令安装多个实例.我尝试使用TRANSFORM，但失败了.我可以手动为实例分配软件包代码吗?如果是，该怎么办?
Can I use msiexec command to install multiple instances. I tried to use TRANSFORM but failed. Can I manually assign Package Code for the instances. If yes, how can it be done?
谢谢.
推荐答案
旧经典 :认真虚拟化.
打包代码 :每个MSI文件的打包代码必须唯一.
Package Code: A package code must be unique per MSI file.
"我想安装一个软件的多个实例.我有多个 不同版本的MSI.但是，这些msi的包装代码 都是一样的."
"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."
这是一个错误.程序包代码是MSI文件的唯一标识符. If two MSI files have the same package code they are by definition the same file as far as Windows Installer is concerned -如果文件确实不同(而不仅仅是同一文件的副本)，则可能导致非常奇怪的问题.
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:
- 打包代码 :标识特定的MSI文件.
- 产品代码 :标识产品版本.
- 升级代码 :标识一系列相关产品.
多个MSI安装实例 :Windows Installer配备不足，无法多次处理同一产品的安装.整个范例假设一个安装实例-以单个绝对安装路径为基础，围绕组件规则及其引用计数为中心实例转换"，但对我来说，它们似乎像事后思考"，被添加以支持需要大量设计更改才能真正起作用的东西.必须经常更改整个应用程序，以便能够和平共存于不同版本中.
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.
旧版Setup.exe :有时人们诉诸旧版setup.exe安装程序，可轻松支持多用户安装. NSIS，Inno， Installshield旧项目等...不太理想，但是它确实提供了相对容易的多次安装.
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.
专业人士缺点 :请快速提醒一下 MSI的最佳功能 ，以及常见问题和一些设计 挑战(朝底部).
Pros & Cons: Just a quick reminder about MSI's best features, as well as common problems and some design challenges (towards bottom).
虚拟化 :虚拟化可能是实现所需功能的最简单方法?在不同的虚拟机中运行不同的应用程序版本，或者使用虚拟化程序包-例如 Microsoft App-V (application streaming - JIT delivery - no local installation per-se，can run incompatible software side-by-side，updating through server，licensing benefits?).然后，将应用程序版本之间的冲突沙盒化".我不得不说，这并不是我最喜欢的概念，但是它适用于许多领域，并且在现实世界中有很多地方.
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 :也许可以考虑使用快速了解MSIX -一种专为Windows 10应用程序设计的新通用软件包格式. 容器" .
MSIX: Maybe consider having a quick read about MSIX - a new universal package format designed for Windows 10 apps. "Containers".
实例转换 :内置的MSI概念是多实例转换.请调查 MSINEWINSTANCE属性并阅读MSI SDK主题:"这也许是一个更好的示例-更多注重实际.我完全避免了这个概念.我相信它可以工作-进行一些计划和应用程序更改.为什么不使用实例转换? 存在一些问题-如Carolyn Napier在此处所述(不确定此特定问题目前是否已解决).总的来说，我发现这个概念并不吸引人-如果需要并行的MSI，我将自己手动"实现"肘部润滑方式"(见下文).
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).
过去的经验 :我之前写过关于多实例安装的主题: 我想两次安装MSI (来自serverfault.com-系统站点) 管理员).
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).
按边并排MSI设置 :可以进行MSI设置，使其始终并排安装-无需使用实例转换.本质上，您需要自己进行所有并排准备，而不会互相干扰. This generally requires major design changes to the application and discipline from the product managers to a degree that is rarely seen . COM服务器通常必须基于清单，并且不涉及注册表. 文件关联不得共享. 共享文件必须完全兼容版本或作为并行程序集安装. MSI组件GUID必须自动生成(( WiX具有功能:自动组件GUID )和每个版本的安装目录必须唯一-可能只是在安装路径中包含版本号.您需要为每个并行流或分支不同的升级代码.等等...清单还在继续.另一种选择是将共享组件放在单独的MSI中，该MSI作为先决条件安装并以其自己的发布周期维护.兼容性问题是可能的.明显地.并行程序集可能会起作用，但它们也不是没有漏洞(发布者策略文件可能会被意外删除-破坏了重定向过程).需要大量的先见之明和肘部润滑脂，但绝对可以带来好处.例如，成功并排安装了产品的UAT和PROD版本.
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:
- 在wix安装程序中禁用修复模式和升级
- 如何创建Windows Installer
- 用蜡生成新的升级代码
- 如何解决并排安装会造成自我修复冲突?(第5节)
- 如何防止Wix安装较旧的版本?(不使用实例转换的并发MSI的挑战)
- 自动方式在InstallShield Basic MSI项目中更新组件代码 (在实例转换中)
- 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)
这篇关于通过具有相同程序包代码的不同msi安装多个实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
