The intent is to generate a stable - the same - component GUID for the same resource. Rob's blog post 'Component Rules 101' describes how multiple components (remember, identified by GUID) installing the same resource can cause problems such as prematurely-removed resources or orphaned resources.
That being so, there should _not_ be any random elements, rebuilding the MSI with the same canonical target paths should yield the same GUID. Your suggestion of hashing the content would break the component rules. If you create a compatible version of a resource, and it is installed to the same place, it should retain the same component GUID. If it is incompatible, you should change the resource's installation location and give it a new GUID. -- Mike Dimmick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Friis Sent: 04 October 2006 08:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Guid="*" I am trying out the new feature Guid="*" as described on http://installing.blogspot.com/2006/09/automatically-generating-component.html I got some questions: In the blog beta-testers are encouraged to try it out: When using it a warning is shown, that this is experimental. Among others it claims that it (the generated GUID, I guess) can "COLLIDE WITH OTHER COMPANY'S PRODUCTS" Is that possible? it of course depends on the generation algorithm. Derek does not ellaborate to much on this: Basically he says that it is "based on a predetermined Wix namespace Guid and the [canonicall] path to the file." Derek encourage users to "Review the overall design for this feature.". In an attempt to review this design, I would ask someone to say some more on this desgin? Questions are: *) Is canonical path and wix namespace te only input to the alforithm, or is there some randomish included as well? Answer is probably yes. *) Does that mean that rebuilding the MSI file with same canonical paths, yield the same GUID? Answer is probably no? *) I suggest that the content (could be md5sum of content) of the key path file should also be an input to the algorithm. This means that e.g. rebuilding a DLL (with even just the smallest change in source code), will result in a new component GUID. Would it be an idea to seperate this feature out to an separate external tool to compute such Guid? Name suggestions "match.exe" or "spark.exe" Jarl -- Jarl Friis Softace ApS Omøgade 8, 2.sal 2100 København Ø. Denmark Phone: +45 26 13 20 90 E-mail: [EMAIL PROTECTED] LinkedIn: https://www.linkedin.com/in/jarlfriis ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
