使用 WiX 3.5，我有一个带有实例转换的 MSI，允许我在同一台计算机上安装具有不同产品名称的软件。为此，我在 .wxs 文件中有条件定义了一个产品 ID 和名称的“硬编码”列表。但是，我只有一个包含文件和非文件资源的 Feature-ComponentRef 定义。
安装似乎工作正常，但卸载实例演示了这两个源中提到的行为：
http://msdn.microsoft.com/en-us/library/aa367797(v=VS.85).aspx
和
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multiple-Instance-Transforms-Walkthrough-Propose-Simple-Addition-to-WiX-to-Make-Them-Easier -td708828.html
具体来说，除了应用程序的最后一个实例之外，没有任何非文件资源（在本例中为注册表项）被卸载。 （即，如果我按以下顺序卸载：实例 1、实例 2 和实例 3 - 仅删除实例 3 的非文件资源。
我认为这与非文件组件没有唯一的 GUID 有关（而这对于文件来说不是问题）因此
，我想知道是否一种有效的方法是定义一个具有一个产品 ID、名称和一组功能的单个 .wxs 文件，但让自定义引导程序为产品和非文件组件生成新的 GUID，然后在运行时插入 MSI 数据库？即，当需要卸载或更新时，我将查询已安装实例的注册表并检索其 GUID，
这将允许在运行时创建实例，而不是在 .提前 wxs，并彻底卸载，
这有意义吗？
Using WiX 3.5, I have an MSI with instance transforms allowing me to install the software on the same machine with different product names. To do this, I have a "hard-coded" list of product id's and names in the .wxs file defined conditionally. However, I have only the single Feature-ComponentRef definition that includes both file and non-file resources.
Installation appears to work fine, but uninstalling the instances demonstrates the behaviour mentioned in these two sources:
http://msdn.microsoft.com/en-us/library/aa367797(v=VS.85).aspx
and
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multiple-Instance-Transforms-Walkthrough-Proposed-Simple-Addition-to-WiX-to-Make-Them-Easier-td708828.html
Specifically, none of the non-file resources (in this case, registry entries) get uninstalled save the very last instance of my application. (i.e., if I uninstall in this order: instance1, instance2, and instance3 - only instance3's non-file resources are removed.
I am presuming this is related to not having unique GUID's for nonfile components (whereas this isn't an issue for file components)
So, I was wondering whether a valid approach would be to define a single .wxs file with one product id, name and one set of features, but have a custom bootstrapper generate new GUID's for the product and non-file components which then get inserted into the MSI database at runtime? i.e., Then when it comes time to uninstall or update, I would query the registry for installed instances and retrieve their GUIDs then.
This would permit instances to be created at runtime rather than hardcoded in the .wxs in advance, and to be uninstalled cleanly.
Does that make sense? Will Burn make everything better? :)
发布评论
评论（2）
从版本 v3.6.1511.0 开始，组件现在有一个“MultiInstance”属性。这允许根据 Josh Rowes 在 WiX 邮件列表的帖子中的建议，为每个实例动态生成一个 guid（请参阅 OP 中的链接）。我已经测试过，这可以正常工作，导致在卸载当前实例时删除注册表数据，而不是在卸载最后一个实例时删除注册表数据。
As of version v3.6.1511.0, there is now a "MultiInstance" attribute for components. This allows a guid to be generated on the fly for each instance as per Josh Rowes suggestion in his post to the WiX mailing list (see the link in the OP). I have tested and this works correctly to cause registry data to be removed when the current instance is uninstalled, and not when the LAST instance is uninstalled.
您不需要拥有唯一的组件 ID，但确实需要拥有唯一的注册表项。查看：
使用实例转换创作多个实例
文章提到：
我实际上不知道他们在那里谈论什么。我创建了 n 层多实例安装程序，其中所有文件都由唯一的 INSTALLDIR 隔离（在运行时键入 51 自定义操作以根据 InstanceID 改变目标），并且所有注册表数据都使用 InstanceID 作为路径的一部分进行改变，如上所述在文章中。我支持多达 16 个具有唯一配置数据和唯一版本号的唯一实例（除了其他实例之外，每个实例都可以通过主要升级来提供服务。）所有这些都是为了支持 nTier 应用程序的 SaaS 部署模型，而我从来没有曾经必须创建具有独特 GUIDS 和/或条件表达式的组件。
我唯一需要做的就是在客户端他们想要在桌面上有一个快捷方式。 （客户端支持多个实例也是因为一个站点在生产中可能有 v1.0，在测试中可能有 v1.1）
因为我无法改变文件夹名称（已修复）并且因为 MSI 的 ShortCut 表不支持 formattable，所以我不得不编写一个自定义操作，使用 InstanceID 在安装表中动态创建快捷方式到 TEMP 表中，然后 MSI 为我创建了快捷方式。
You don't need to have unique component ID's but you do need to have unique registry keys. Check out:
Authoring Multiple Instances with Instance Transforms
The article mentions:
I actually don't know what they are talking about there. I created n-Tier multiple instance installers where all the files were isolated by unique INSTALLDIR ( type 51 custom action at runtime to mutate the destination based on the InstanceID ) and all the registry data was mutated using the InstanceID as part of the path as mentioned in the article. I supported up to Sixteen unique instances with unique configuration data and unique version #'s ( each instance could be serviced via major upgrade apart from the other instances. ) All of this was to support a SaaS deployment model for an nTier application and I never ever had to create components with unique GUIDS and/or Conditional expressions.
The only thing wonky I had to do was on the client side they wanted a Shortcut on the desktop. (The Client supported multiple instances also because a site might have v1.0 in Production and v1.1 in Test )
Because I couldn't mutate the folder name (fixed) and because MSI's ShortCut table doesn't support formattable, I had to write a custom action to author the ShortCut dynamically at install table using the InstanceID into a TEMP table and then MSI created the shortcut for me.