Thanks for all the pointers! I grouped the non file data in this recommended method and it is working beautifully. Thanks! Uma-
-----Original Message----- From: John Nannenga [mailto:john.nanne...@microsoft.com] Sent: Wednesday, December 09, 2009 7:50 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Here's the key point from the SDK: * 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. The emphasis here is on "nonfile data"; which includes (but not limited to) shortcuts, registry items, ini items, ODBC items [and the list goes on and on]. You do not 'have' to do this for "file data". The SDK recommendation here is to (if you're going to support multiple instances) segregate nonfile data into their own components which would then have their own unique component GUIDs and installed conditionally based upon the instance identifier. To answer your question then, Uma: "I find that HKLM\Software\ESRI\Instance1 is still left behind on the machine after instance 1 is uninstalled. Is this because the component that includes this registry key is still in the installed state with the base setup?" I believe that occurs because the component was ref-counted. What you would see then is that when the last instance is uninstalled, the registry information for only that instance would be removed, but all the other instance registry keys would remain (thus, orphaned). You can also run into this situation when you upgrade a product and are performing 'efficient upgrades' where the registry information location for that instance changes. You'll need to change the component GUID in this situation as well. ________________________________________ From: Michael Osmond [mosm...@baytech.com.au] Sent: Monday, December 07, 2009 5:46 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Hi If you are using MSI Instances and installing to different locations, you don't need different component GUIDs for each component in each installed instance and the reference counting seems to work okay. I will be honest and say I don't know how it works under the hood, but it does work. The installer is able to work out where things are. I do however use a registry key for each instance to keep the path where I installed that instance too, which comes in handy on major upgrades. Also have found it usefull to record the product ID of the instance in the registry as well. Michael ________________________________________ From: kelly.le...@milliman.com [kelly.le...@milliman.com] Sent: Tuesday, 8 December 2009 9:32 AM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi I wasn't asking about ProductCode. I'm asking about the component GUID for the registry key you're referring to. You need to assign different GUIDs for all components that could be installed in two locations by the two different instances. If you want to install the same files in two places, you're going to have to modify all the component GUIDs for the files, if I understand the process correctly. I'm not an expert on using instance transforms to install multiple instances, but it seems like no matter what you do, you can't break the component rules. Otherwise, it won't install the files to the "new" locations, since it will think they are already installed (based on the component ID and its installed state). Kelly Uma Harano <uhar...@esri.com> 12/07/2009 03:24 PM Please respond to "General discussion for Windows Installer XML toolset." <wix-users@lists.sourceforge.net> To "General discussion for Windows Installer XML toolset." <wix-users@lists.sourceforge.net> cc Subject Re: [WiX-users] Instance transforms with the msi Each instance has a unique Product Code. Also, I was following the guidelines from the Windows installer SDK (On how to author instance transforms). How do I install the same set of files for multiple instances using transforms? Please advise! Uma- Here is the windows installer sdk topic on this: Authoring Multiple Instances with Instance Transforms To install multiple instances of a product from one Windows(r) Installer package, you need to author a base installation package for the product and an instance transform for each instance to be installed in addition to the base instance. Use the following guidelines when authoring your base package and transforms: *Your setup application can check for the presence of the installer running on a version of the Microsoft(r)Windows Server 2003 family, Windows XP SP1, Windows 2000 SP4 and the Windows Installer 3.0 redistributable. Any of these installer versions (or later) are required to install multiple instances from a single package using a product code-changing transform. * Each instance must have a unique product code and instance identifier. You may define a property in the base package, the value of which can be set to the instance identifier. * To keep the files of each instance isolated, the base package should install files into a directory location that depends on the instance identifier. * 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. * Author an instance transform for each instance being installed in addition to the base instance. The base package may install its own instance. * The instance transform must change the product code and identifier for each instance. * It is recommended that the product transform also change the product name so that the instance is readily distinguished in Add/Remove Programs through Control Panel. * If the instance transform installs files, they should be installed in a directory that depends on the instance identifier. * All nonfile data, such as registry keys, should include the instance name in their path to prevent collisions. This can be accomplished by using the property whose value is the instance identifier in the path as shown by the following example of a Registry Table. -----Original Message----- From: kelly.le...@milliman.com [mailto:kelly.le...@milliman.com] Sent: Monday, December 07, 2009 2:52 PM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Are you using the same component GUID for each of these keys? You can't do that... It's breaking the component rules and all kinds of bad things happen when you break the component rules. Each distinct component keypath (the 'main' entry in a component) MUST have a unique component GUID. Each distinct component GUID can only be installed in one place on a given machine (you can't try to install the same GUID to two different keypaths). Kelly Uma Harano <uhar...@esri.com> 12/07/2009 02:47 PM Please respond to "General discussion for Windows Installer XML toolset." <wix-users@lists.sourceforge.net> To "General discussion for Windows Installer XML toolset." <wix-users@lists.sourceforge.net> cc Subject [WiX-users] Instance transforms with the msi Hi, I am using instance transforms (msts) to install multiple instances of my base product (msi) on the same machine. Everything works except for one issue: I use an instance identifier property [INSTANCEPROP] that gets set to"Instance1", "Instance 2",...etc for each instance. I use this property to write registry keys for each instance. For example - HKLM\Software\ESRI\[INSTANCEPROP] is written via the registry table (One record in the registry table to linked to one component). When multiple instances are installed, this key could be repeated multiple times, but they would all be in their own hive HKLM\Software\ESRI\ Instance1 HKLM\Software\ESRI\ Instance2 HKLM\Software\ESRI\ Instance3 Etc Scenario: The base setup and an instance 1 is installed, I uninstall the instance 1. I find that HKLM\Software\ESRI\Instance1 is still left behind on the machine after instance 1 is uninstalled. Is this because the component that includes this registry key is still in the installed state with the base setup? What would be the best way to ensure that the HKLM\Software\ESRI\Instance1 get removed when instance 1 is uninstalled? Should I make multiple components in the msi each with unique conditions for each transform? Or create a custom action that deletes the registry entry for each transform? Thanks! Uma Harano ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ************************************************************************************** This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Unless indicated to the contrary: it does not constitute professional advice or opinions upon which reliance may be made by the addressee or any other party, and it should be considered to be a work in progress. Unless otherwise noted in this email or its attachments, this communication does not form a Statement of Actuarial Opinion under American Academy of Actuaries guidelines. ************************************************************************************** ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ************************************************************************************** This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Unless indicated to the contrary: it does not constitute professional advice or opinions upon which reliance may be made by the addressee or any other party, and it should be considered to be a work in progress. Unless otherwise noted in this email or its attachments, this communication does not form a Statement of Actuarial Opinion under American Academy of Actuaries guidelines. ************************************************************************************** ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
