我们有一个使用wix创建msi的独特要求，问题是msi必须支持多个实例安装。用户应该能够使用msi在特定系统上多次安装产品，因此为了实现这一点，我们应该在msi中禁用修复模式和升级，因此几乎每次调用msi都应该被视为全新安装。 / p>
上述要求在技术上是否可行？我知道，每次调用msi时都有唯一的产品代码和包代码会将安装视为全新安装。这可以使用msi周围的包装器来实现吗？
答案 0 :(得分：0)
在将您发送到MSI SDK之前，我应该添加我自己不喜欢这个实例转换概念，并且在实践中没有使用它。可能是我变成了一个脾气暴躁的老头！ ： - 。）
MSINEWINSTANCE ：请调查MSINEWINSTANCE property并阅读MSI SDK主题：“Installing Multiple Instances of Products and Patches”。 here is perhaps a better example - 更具实际导向性。
另外some context说明为什么我不太热衷于此功能。卡罗琳·纳皮尔（Carolyn Napier）是最初的MSI团队 - 正如他们所说的那样，直接来自马的嘴巴。
我知道有些人声称这些实例转换成功（Chris Painter可能会在这里说明我的主张），但我宁愿虚拟化这些场景。 请查看来自serverfault.com的这篇古老帖子 ：I want to install an MSI twice（请同时浏览该“帖子”中的所有其他答案）。
APP-V ：我的App-V经验几乎为零，但我的猜测是，您应该尝试说服您的经理花些钱调查时间。也许可以打电话给一些人，并与当前部署中有效的人交谈。他们总是对当前普遍存在的偏见进行报道 - 这些技巧使得现实世界中的事物发挥作用。
如果您能告诉我们您最终解决问题的方法 ，那就太棒了。
禁用修复＆amp;修改 ：对于记录：disabling repair and modify (buttons only)可以通过设置ARPNOMODIFY和ARPNOREPAIR属性来完成。但这不是您要求允许多个实例安装的内容。 MSI不容易被愚弄并且知道你已经安装了什么以及什么时候 - 没有理由浪费时间测试这些“选项”。 所有这两个属性都是隐藏或禁用修改和修复按钮 - 除此之外不会产生任何需要。
答案 1 :(得分：0)
您可以使用MSI周围的包装器来完成此操作。通常，您的包装器程序将从基本MSI开始，使用Windows Installer API更改ProductCode和PackageCode，将此MSI复制到系统上的某个位置，然后从那里安装它。
我说＆＃34;复制并安装＆＃34;因为尝试禁用修复是徒劳的 - 它已经融入了Windows Installer的体系结构。如果您将每个单独的MSI产品缓存在某处，那么修复将使用该唯一的MSI工作，这也意味着您也可以进行修改。修复太难以预测，无法完全预防。任何共享文件都可以从共享它们的其他已安装产品中触发修复。如果客户意外删除文件或注册表项，客户会怎么做？并且有关于保持源MSI可用的问题，尽管原因列表并未提供大量解释，规则31：
还有很多其他问题没有提到，所以你不清楚你是否关心补丁和维护，关于程序/功能中的多个条目（你可以抑制，但是你如何卸载？）等等。同样不清楚的是，这些单独的安装中的每一个都不以任何方式相互冲突，例如公共文件/注册表项，服务名称，安装在具有相同名称的相同位置的文件。