I understand how the GUIDs are generated. My question goes deeper and hits at the annoyances of needing components and GUIDs in general but I'll leave that for a blog post some day.
---------------------------------------- From: "Peter Shirtcliffe" <[email protected]> Sent: Wednesday, September 28, 2011 6:52 AM To: "General discussion for Windows Installer XML toolset." <[email protected]> Subject: Re: [WiX-users] GUID vs. * for components (Was: RE: WiX-usersDigest, Vol 64, Issue 49) This may clear up your confusion. The * guid is generated based on the path in the installer at build time, not based on the path with the substitutions made at install time. For example: A component's path at build time is [ProgramFilesFolder]\Company\INSTALLDIR A component's path at install time might resolve to c:\Program Files\Initech\Widget1 The * guid is generated based on the first version, the unresolved path. This is still valid under the component rules because they allow the same component to be installed into multiple locations by different installers as long as the unresolved paths are the same. -----Original Message----- From: Christopher Painter [mailto:[email protected]] Sent: 28 September 2011 12:22 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] GUID vs. * for components (Was: RE: WiX-usersDigest, Vol 64, Issue 49) You have to implement ComponentGuidGenerationSeed to use "*" in a merge module and you wouldn't if you used a fragment instead. I wonder if WiX could be changed to just use the Module Id for it's GUID by default? My point still stands though as an MSI can have it's INSTALLDIR changed so the whole thoery around we know the absolute path so therefore we can randomize GUIDs confuses me a little. You never fully know the path until after the install is done. In my IsWiX tool I have hashing for the Id's but they are then modularized to full ensure uniqueness. I've been creating GUIDs but while this all works perfectly it's not the prettiest most expressive XML in the world. I'd love to be able to reduce the clutter of all the guids and hashes. ---------------------------------------- From: "Rob Mensching" <[email protected]> Sent: Tuesday, September 27, 2011 11:30 PM To: [email protected], "General discussion for Windows Installer XML toolset." <[email protected]> Subject: Re: [WiX-users] GUID vs. * for components (Was: RE: WiX-users Digest, Vol 64, Issue 49) AFAIK, merge modules aren't treated differently from MSIs wrt * GUID. On Tue, Sep 27, 2011 at 6:22 AM, Christopher Painter <[email protected]> wrote: Rob, Has WiX implemented "*" for Merge Modules yet? I understand Merge Modules are retargetable but then again any MSI is really retargetable by changing the value of TARGETDIR/INSTALLDIR/INSTALLLOCATION et al. That of course has always struck me as odd about the whole MSI Component ID paradigm as the absolute path to the keypath is never truly absolute. Chris ---------------------------------------- From: "Rob Mensching" <[email protected]> Sent: Tuesday, September 27, 2011 8:01 AM To: "General discussion for Windows Installer XML toolset." <[email protected]> Subject: Re: [WiX-users] GUID vs. * for components (Was: RE: WiX-users Digest, Vol 64, Issue 49) Well, my opinion is my opinion. People are welcome to disagree with my opinion <smile/> For example, a few people around here (including some clients) disagree with me whether MajorUpgrade/@AllowSameVersionUpgrades is a "good thing" or not. It's only when something *really* doesn't work and people want to disagree that the world has issues. <smile/> Anyway, to answer your question. The advantage of "*" GUID over explicit GUID is that you don't have to provide a GUID. IN WiX v3.6 we've gone as far as to make the Component/@Guidoptional so you can leave the attribute off completely and get the "*" GUID behavior. Previously (before WiX v3.5, I think) we did not provide the option of "*" GUID because we did not have a mechanism to maintain a stable GUID across builds. It was a really gnarly problem that took us a while to finally come up with a (IMHO) really nice solution. Basically, the GUID is generated from a hash of the *target path* of the KeyPath of the Component. If the target path changes, the GUID changes. This aligns perfectly with the Component Rules ( http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101) as long as you don't change the other resources in there. That's where most of the restrictions come from. To really understand I suggest reading that link above. If you have already shipped then you need to keep the same GUIDs unless you change the Component in such a way that a new GUID is required (see how "*" might be nicer, you don't have to think about that). If you do an early MajorUpgrade ("afterInstallValidate" or "afterInstallInitialize") then you can change all your GUIDs as long as nothing is shared with other products (again, see how "*" is much nicer, you don't have to think about that either). The Component Rules are a pain. But they are the foundation of the Windows Installer so understanding them has a lot of value. <smile/> -- virtually, Rob Mensching - http://RobMensching.com LLC On Mon, Sep 26, 2011 at 10:12 PM, Thomas Due <[email protected]> wrote: > And I would think your opinion carries at least SOME weight on the issue > *grin* > > A follow up question though, I have a hard time understanding the > difference of the two. > All the documentation is a bit on thin side, or I do simply not understand > the issue. > > So, to refrase, what are the advantages to using * opposed to GUIDS? > And vice-versa. > > In my current situation I have two installers sharing a wixlib with several > components in it. > Now, one of the installers have been in production use for some time, but > we are using a major upgrade model everytime. > So, is there any danger in changing all the component GUIDs to *? > > Med venlig hilsen / Best regards > Thomas Due > Software udvikler > Scanvaegt Nordic A/S > > -----Original Message----- > From: Rob Mensching [mailto:[email protected]] > Sent: 26. september 2011 15:44 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] WiX-users Digest, Vol 64, Issue 49 > > Either is actually an option (because the file paths will be changing, > presumably). I would use the "*" GUID, but I try to use "*" GUID for > everything. > > On Mon, Sep 26, 2011 at 6:21 AM, Thomas Due <[email protected]> wrote: > > > Hello, > > > > I am currently "struggling" with two installer packages. One is done, and > > the other is coming along nicely. > > However, the applications they each install shares a set of assemblies > > which I am thinking of putting in a common wix library. > > Each installer will install the assemblies into separate folders, so each > > assembly has the potential to be installed once by each installer. > > It would be ideal to install these to a common location, but that would > > require som restructuring and redesign of our application, so that is not > an > > option at the moment. > > > > Now my question is: If a set of assemblies is shared by two different > > installers, what would be the best way to set the GUID on the components > > containing these assemblies? > > Should I set a fixed GUID, or use an *? > > > > > > > > > > Med venlig hilsen / Best regards > > Thomas Due > > Software udvikler > > Scanvaegt Nordic A/S > > ________________________________________ > > Fra: [email protected] [ > > [email protected]] > > Sendt: 26. september 2011 13:40 > > Til: [email protected] > > Emne: WiX-users Digest, Vol 64, Issue 49 > > > > Send WiX-users mailing list submissions to > > [email protected] > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.sourceforge.net/lists/listinfo/wix-users > > or, via email, send a message with subject or body 'help' to > > [email protected] > > > > You can reach the person managing the list at > > [email protected] > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of WiX-users digest..." > > > > > > > ---------------------------------------------------------------------------- -- > > All the data continuously generated in your IT infrastructure contains a > > definitive record of customers, application performance, security > > threats, fraudulent activity and more. Splunk takes this data and makes > > sense of it. Business sense. IT sense. Common sense. > > http://p.sf.net/sfu/splunk-d2dcopy1 > > _______________________________________________ > > WiX-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > -- > virtually, Rob Mensching - http://RobMensching.com LLC > > > ---------------------------------------------------------------------------- -- > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > WiX-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wix-users > > ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC ---------------------------------------------------------------------------- - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. ---------------------------------------------------------------------------- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users
