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