MSI / WIX - 在多个实例转换期间分配组件GUID

Question

使用wix 3.5，我有一个msi，用实例转换，允许我在同一台计算机上安装软件，其中包含不同的产品名称。为此，我有一个“硬编码”的产品ID列表和.wxs文件中的名称。但是，我只拥有包含文件和非文件资源的单个特征-compentref定义。

安装似乎正常工作，但卸载实例演示了这两个来源中提到的行为：

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-proposed-simple - addition-to-wix-to-make-tom-emier-td708828.html 具体而言，没有任何非文件资源（在这种情况下，注册表项）卸载保存我的应用程序的最后一个实例。 （即，如果我按此顺序卸载：instance1，instance2和instance3 - 只删除instance3的非文件资源。

我推测这与非文件组件没有唯一的GUID（而这不是文件组件的问题）

所以，我想知道一个有效的方法是否是使用一个产品ID，名称和一组功能定义一个.wxs文件，但是具有自定义引导器为产品和非文件组件生成新的GUID然后在运行时将MSI数据库插入MSI数据库？即，然后，当卸载或更新时间时，我会查询已安装实例的注册表并检索其GUID。

这将允许在运行时创建的实例，而不是预先在.wxs中进行硬编码，并清洁卸载。

这有意义吗？会烧得更好吗？ :)

Answer 1

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.

Answer 2

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:

To keep the nonfile data of each instance isolated, the base package should collect nonfile data into sets of components for each instance. The appropriate components should then be installed based on conditional statements that depend on the instance identifier.

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.