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:***@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 [***@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: ***@Milliman.com [***@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 <***@esri.com>
12/07/2009 03:24 PM
Please respond to
"General discussion for Windows Installer XML toolset."
<wix-***@lists.sourceforge.net>
To
"General discussion for Windows Installer XML toolset."
<wix-***@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: ***@Milliman.com [mailto:***@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 <***@esri.com>
12/07/2009 02:47 PM
Please respond to
"General discussion for Windows Installer XML toolset."
<wix-***@lists.sourceforge.net>
To
"General discussion for Windows Installer XML toolset."
<wix-***@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-***@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-***@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-***@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-***@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-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users