Hi Aaron-
I'd really have to have a long talk with you to fully understand what you are
doing but my hunch is that your custom actions and registry searches are over
complicating the problem. You might want to look into things such as
MsiEnumRelatedProducts to let you make the jump from UpgradeCode to ProductCode
without having to know the ProductCode. Also when I did Multiple Instance
MSI's in InstallShield my setup.exe bootstrapper handled most of the servicing
( see my blog article that I linked ) and applied the instance transforms when
invoking my installs. My installs generally needed to know very little that
it was another instance of an existing install. I had very few custom actions.
Regards,
Chris
---
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention? E-Mail Me
--- On Mon, 5/9/11, Aaron Klor <aaron.k...@gmail.com> wrote:
From: Aaron Klor <aaron.k...@gmail.com>
Subject: Re: [WiX-users] [Wix-users] Less than completely random ProductCodes
To: chr...@deploymentengineering.com, "General discussion for Windows Installer
XML toolset." <wix-users@lists.sourceforge.net>
Date: Monday, May 9, 2011, 11:32 AM
I appreciate that input tremendously! I had figured that the replies here would
be something to that effect (thanks to David also). Really, all that we need is
a deterministic way to generated GUIDs (to GREATLY simplify our WiX authoring
and maintaining), and we had thought that something like this would simplify
the writing and testing of that function.
To address the responses:
David: All of the information that we are talking about putting into the
guid is already in the values of the key that is generated using this guid (in
the software\microsoft\windows\currentversion\uninstall (ARP) key), and the
information storage isn't really the point of this guid anyway. Thank you
though.
Chris: I appreciate your candor. We are not entirely in love with the scheme
that I presented before either. It just seems that our process for this could
be greatly simplified by doing this. By using a deterministically generated
guid (we don't NEED all that information embedded in the guid, could look
random), we are able to determine what, if any instances are installed (at
runtime), use a custom preprocessor to generate the InstanceTransforms element,
and create and schedule custom actions (two per instance) to perform major
upgrades on specific instances (rather than all at the same time). Also, we
have several different products, some of which depend on others to be
installed, and must be installed to a specific directory based on a specifc
instance (selected by user at runtime) of their prerequisites' install
location. This would allow the registry searches for those products to be
greatly simplified as well, again using either a preprocessor
or some custom actions at runtime.
Really, all of this stems from the fact that to upgrade a specific instance of
an installed product, that instance has to have a different upgrade code AND
product code, from any other installations. Once that is realized, we must then
schedule custom actions to change those codes at runtime based on the transform
selected. Then we have to keep track of all of the instances' codes within the
MSI, our solution being a custom table. Then we must also keep track of those
codes for the other products who rely on that to be installed to find the
install location. The net effect being that if we want to support 100
instances, we'd have to wrangle 1000's of guids for every release, plus
maintain a couple thousand lines of WiX that consists of mostly copy/paste work.
We would love to not violate the randomness of GUIDs, so if there is a way to
do what we intend without deterministically generating GUIDs, we would be very
happy, but so far we have been unable to find a way.
Thank you very much again,
Aaron
On Mon, May 9, 2011 at 9:25 AM, Christopher Painter
<chr...@deploymentengineering.com> wrote:
IMO, I don't ever do this. I really don't care who does and what reasons they
come up for doing it, I don't and will not ever do it. I also generate
ProductCodes at build time to support major upgrades. I've also generated
multiple instance installers where I generate new guids for each of the
instance transforms.
I have no intention of trying to put that level of meaning to a really big ass
random number. I track my UpgradeCodes and release / labels and versions but
not my ProductCodes and PackageCodes. I just let them be randomized.
Chris
---
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention? E-Mail Me
--- On Mon, 5/9/11, Aaron Klor <aaron.k...@gmail.com> wrote:
From: Aaron Klor <aaron.k...@gmail.com>
Subject: [WiX-users] [Wix-users] Less than completely random ProductCodes
To: "General discussion for Windows Installer XML toolset."
<wix-users@lists.sourceforge.net>
Date: Monday, May 9, 2011, 9:12 AM
We are considering defining our product codes for our different instances
with a bit more structure than the random GUID generation that is usually
recommended. We are considering this because we have to define a large
number of product code GUIDs for each product AND change them every time we
do a build. There is precedent for this sort of behavior (set by the
Micrsoft Office team, see
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\90140000-XXXX-XXXX-0000000FF1CE),
so we've decided to ask the list in order to hopefully gain some insight as
to whether this is considered “bad form” or if this might be acceptable.
For reference, we were considering something of this form:
{XXXXXXXX-XXXX-XXXX-CoPr-MaMiRvBildIn}
Where the X’s are randomly generated GUID bits, but will be the same
throughout our products
The description of the rest of the fields are:
Co: 8-bit company code (human-readable, using A-F)
Pr: 8-bit product code (human-readable, using A-F)
Ma: Major rev
Mi: Minor rev
Rv: Revision
Bild: Build number
In: Instance number
We understand that this significantly reduces the randomness of the GUID
(potentially removing the GU part of GUID), but given the manageability
gains, we feel that it might be worth it. It gives us the ability to easily
generate (and programmatically search for) up to 255 instances, allows for
revisions up to 255.255.255.65535, and can potentially simplify our WiX
authoring.
Obviously, this will cause problems in the case a GUID collision occurs
between our product and someone else's, but we find this highly unlikely
given that there are still 64 random bits in the GUID. I suppose the real
question is: is there something that we're missing? Might this sort of thing
affect things outside the ARP on Windows machines?
Thank you for your help,
Aaron Klor
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
