(Posting this into wix-devs as I've gone from a problem to a proposed
solution.)
Searching the archives, I found this reference
(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-shoul
d-I-be-upgrading-one-of-multiple-installed-instances-of-an-application-t
d6754871.html). On Sep 02, 2011 Rob had commented:
"
I think there is a feature request open to allow WiX to updated the
UpgradeCode for each instance transform. It just hasn't been
implemented.
Same could be done for the ProductCode but I'd have to investigate to
see if
there are reasons why "*" isn't allowed right now.
"
I've found 3223373 which is the request for allowing UpgradeCode
to be specified on the Instance element. I cannot seem to find a bug or
feature request with regards to using * for the ProductCode. Rob, any
comments as to if you think either of these would be implemented any
time soon?
For the * in the ProductCode, I believe this would be as simple as
modifying Compiler.ParseInstanceElement (in Compiler.cs) near line 1007
from:
case "ProductCode":
productCode =
this.core.GetAttributeGuidValue(sourceLineNumbers, attrib, false);
break;
to:
case "ProductCode":
productCode =
this.core.GetAttributeGuidValue(sourceLineNumbers, attrib, true);
break;
For 3223373, this method would also need to be modified and the
WixInstanceTransforms table have an additional field of UpgradeCode
added to it. I can also see Binder.CreateInstanceTransform needing
modifications to add an UpgradeCode row to the property table. In
addition, we would either need to transform the Upgrade table to replace
the UpgradeCode in all rows of the existing Upgrade table or I'd have to
see if it's allowable to have multiple Upgrade elements under a product
with each of the predefined constant upgrade codes. (The former seems
cleaner, if it is possible to get the Upgrade table.) Ex:
Table wixUpgradeTable = output.Tables["Upgrade"];
if (null != wixUpgradeTable && 0 <= wixUpgradeTable.Rows.Count)
{
string upgradeId = (string)instanceRow[4]; ' This assumes we
added UpgradeCode as the 4th field in the WixInstanceTransforms table
string actionProperty = null;
string language = null;
string maximum = null;
string minimum = null;
int options = 256;
string removeFeatures = null;
Table upgradeTable =
instanceTransform.EnsureTable(this.core.TableDefinitions["Upgrade"]);
foreach(Row row in wixUpgradeTable.Rows)
{
Row upgradeRow =
upgradeTable.CreateRow(row.SourceLineNumbers);
upgradeRow.Operation = RowOperation.Modify;
upgradeRow.Fields[0].Modify = true;
upgradeRow[0] = upgradeId;
upgradeRow[1] = minimum;
upgradeRow[2] = maximum;
upgradeRow[3] = language;
upgradeRow[4] = options;
upgradeRow[5] = removeFeatures;
upgradeRow[6] = actionProperty;
}
}
So, assuming others would like this functionality, shall I get to
creating a fork, implementing the changes, and initaiting a pull
request? (Also, what kind of unit tests would need to be added to
./test/src/Integration/BuildingPackages/InstanceTransforms.InstanceTrans
formTests.cs?)
Jacob
-----Original Message-----
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Friday, November 04, 2011 10:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Best approach for multi-instance installers.
Hi,
I'm currently trying to optimize the MSI generation for our software.
Using suggestions found on Stack Overflow I've been able to generate a
single project with variable WXI files in order to generate my
dev/test/live MSI's (the WXI's simply defining a list of unique
component ID's, instance location, etc). I'm now wondering if there
would be a safe/predictable manner in which to only generate a single
MSI per binary build (and possibly generate a targeted MSI by applying a
transform on a release event).
The Wix 3.6 component property MultiInstance seems to be exactly what
I am looking for, but I was looking for a sanity check before I go down
this road. If I am understanding the bits and pieces I've found, I could
create an instance transform for each dev/test/live that would change
the product code, upgrade code, instance location, misc UI text, and
embed them within the MSI. Then, with this single MSI I could use my
boot strapper to apply the appropriate transform.
I'm also seeing an InstanceTransforms and Instance element in the
documentation, but Instance doesn't allow for specifying an UpgradeCode.
Since my need is to provide an updated Develop MSI before test and live,
I would need a unique UpgradeCode in order to only upgrade the develop
instance without upgrading the others. Would I have to generate a second
transform to update the UpgradeCode, or is there a means within the
existing Wix multi-instance framework to do so?
If this is correct, then can we confirm that the major upgrade,
uninstall, and repair functionality would all remain intact? (I would
venture to guess the transforms applied to the source database are
stored in the registry under the product code.) Would it be possible to
deny running the MSI directly to enforce that a transform has been
applied? Assuming the structure of the installer hasn't changed, can
the transforms be reused for multiple builds of the installer?
Thanks,
Jacob
------------------------------------------------------------------------
------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
