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
