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" <r...@robmensching.com> Sent: Tuesday, September 27, 2011 8:01 AM To: "General discussion for Windows Installer XML toolset." <wix-users@lists.sourceforge.net> 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 <t...@scanvaegt.dk> 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:r...@robmensching.com] > 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 <t...@scanvaegt.dk> 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: wix-users-requ...@lists.sourceforge.net [ > > wix-users-requ...@lists.sourceforge.net] > > Sendt: 26. september 2011 13:40 > > Til: wix-users@lists.sourceforge.net > > Emne: WiX-users Digest, Vol 64, Issue 49 > > > > Send WiX-users mailing list submissions to > > wix-users@lists.sourceforge.net > > > > 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 > > wix-users-requ...@lists.sourceforge.net > > > > You can reach the person managing the list at > > wix-users-ow...@lists.sourceforge.net > > > > 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 > > WiX-users@lists.sourceforge.net > > 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 > WiX-users@lists.sourceforge.net > 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 WiX-users@lists.sourceforge.net 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 WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
