inline On Tue, Jan 15, 2013 at 3:42 PM, Heath Stewart <[email protected]> wrote:
> But if two wixlibs define it, you get a duplicate symbol error. I’m > building off your previous examples where you had something like this:**** > > ** ** > > a.swr -> a.wixlib**** > > folder name=InstallFolder:\Foo**** > > file name=a.dll**** > > ** ** > > b.swr -> b.wixlib**** > > folder name=InstallFolder:\Foo\Bar**** > > file name=b.dll**** > > ** ** > > Foo ends up getting defined in both a.wixlib and b.wixlib, so that when > you link them you get a duplicate symbol error. If I do what you’re > suggesting – where they have to be declared – > If I read your last sentence correctly, I'm actually suggesting the exact opposite. I'm suggesting that these not create problems because no folders here have been defined with an explicit id. > I don’t see the point in having anonymous IDs anyway:**** > > ** ** > > Product.wxs -> product.wixobj + a.wixlib + b.wixlib -> product.msi**** > > <Fragment>**** > > <DirectoryRef Id=”InstallFolder”>**** > > <Directory Id=”FooFolder” Name=”Foo”>**** > > ** ** > > a.swr -> a.wixlib**** > > folder id=FooFolder extern**** > > file name=a.dll**** > > ** ** > > b.swr -> b.wixlib**** > > folder id=FooFolder extern**** > > folder name=FooFolder:\Bar**** > > file name=b.dll**** > > ** ** > > Here we had to define “Foo” somewhere in order to define the ID we must > link to. We already have to do that today – at least across different > wixobjs or wixlibs. Within the same cascading elements – both in twix and > swix – we can seed child IDs – either temporary IDs (ex: RowId) or the > final primary keys/IDs.**** > > ** ** > > But where does this stop? A team may not know that FooFolder:\Bar is going > to be a leaf node (directory) across the entire product for a large product > such as Visual Studio. So everyone ends up declaring IDs anyway.**** > > ** ** > > So in order to support where multiple Output objects *define* the same > directory like below, we should basically treat all directories as > “partial” (as in C# partial classes) so that the directory can be defined > (Directory) the first time (the first time it gets processed by the linker) > and treated as extern (DirectoryRef) any time thereafter:**** > > ** ** > > a.swr -> a.wixlib**** > > folder name=InstallFolder:\Foo**** > > file name=a.dll**** > > ** ** > > b.swr -> b.wixlib**** > > folder name=InstallFolder:\Foo\Bar**** > > file name=b.dll**** > > ** ** > > c.swr -> c.wixlib**** > > folder name=InstallFolder:\Foo\Baz**** > > file name=c.dll**** > > ** > This all looks fine to me. > ** > > *Heath Stewart***** > > VS Pro Deployment Experience, Microsoft > http://blogs.msdn.com/heaths**** > > ** ** > > *From:* Rob Mensching [mailto:[email protected]] > *Sent:* Tuesday, January 15, 2013 3:18 PM > > *To:* Heath Stewart > *Cc:* Windows Installer XML toolset developer mailing list > *Subject:* Re: [WiX-devs] Merging directories at link time**** > > ** ** > > Would it be easier to just note that "Foo" is an explicit Id and let the > linker error fail like it does today?**** > > ** ** > > On Tue, Jan 15, 2013 at 1:23 PM, Heath Stewart <[email protected]> wrote: > **** > > For clarification on using the Differ: I mentioned using the Differ to > help solve the case where you had the following example:**** > > **** > > [a.swr]**** > > <Fragment>**** > > <Property Id=”A” …/>**** > > <Directory Id=”Foo” …/>**** > > **** > > [b.swr]**** > > <Fragment>**** > > <Property Id=”B” …/>**** > > <Directory Id=”Foo” …/>**** > > **** > > **** > > Now, when merging directory “Foo”, we will get either property A or B or > both depending on which wixlibs we link to (which, because of merging, > doesn’t force either A or B – just one of them). You didn’t want that > behavior, while I’m arguing that VC/C++ allows it but doesn’t really > document it (i.e. it’s not a supported feature but some might find useful). > If we absolutely did not want that behavior, we could diff the fragments to > make sure that any fragment with a directory being merged are exactly the > same or raise and error (either the DuplicateSymbol error, or another > similar one but more specific to having duplicate directory symbols that > different in their fragments’ definition).**** > > **** > > **** > > *Heath Stewart***** > > VS Pro Deployment Experience, Microsoft > http://blogs.msdn.com/heaths**** > > **** > > *From:* Heath Stewart [mailto:[email protected]] > *Sent:* Wednesday, January 9, 2013 4:17 PM > *To:* 'Rob Mensching'**** > > > *Cc:* 'Windows Installer XML toolset developer mailing list' > *Subject:* Re: [WiX-devs] Merging directories at link time**** > > **** > > Yes, one could argue that is a cool feature but the subtle ways that can > go wrong do not offset the advantages. Also, if only identical Directory > rows are allowed to be duplicated then the subtle cool feature only can be > done with Directory elements. It feels sketchy all the way around and if we > really want to do said feature, I really want to dig into all the ways it > could go wrong.**** > > **** > > I don’t think we should tout is as a feature (AFAIK, cl/link.exe don’t > either) but I’m not sure how else we’d solve this. If two wixlibs – and I’m > mainly thinking swix here because of the new directory spec syntax – > attempt to define the same folder I can’t see how we could fail. Authoring > would become a nightmare and the only sane solution would seem to be that > setup devs have to define their folder structure separately (i.e. its own > wixlib) which, IMO, negates the ease of the new directory spec (i.e. > root:\dir\subdir). If the property and the folder would be in the same > section (which, in twix, they would – not sure off hand if that’s even > possible in swix and I know, at least, folders go to their own sections) we > could maybe throw a dup symbol exception if the Differ found any > non-directory differences in that section (would be a new call, but off > hand wouldn’t be any major change). I wonder if this is overkill, though > (and will increase build time). I doubt many people would do it, especially > if the majority/all of their resource authoring (directories, files, > registry) is in swix. I know a certain group will have a lare mix of twix > and swix but we plan on reigning in authoring of roots and most directory > authoring is already isolated from other authoring.**** > > **** > > I'm not worried about anonymous, duplicate Directory rows being merged > because they can never cause the issue I point out above.**** > > **** > > I don’t follow. If anonymous directories resolve to the same path, the > generated Id in the BackendCompiler would be the same since the name, > parent name, and seed values to the hash generation would be the same. So > even anonymous IDs in swix that resolve to the same directory would have to > be merged. It was this realization when attempting to design a full > anonymous ID solution that lead me to consider just merging directories’ > symbols.**** > > **** > > The Simplified WiX compiler sees that "a" is not rooted in a well-known > root, so it roots it InstallFolder. So a.swr file ends up actually being:* > *** > > **** > > Ah, I didn’t realize that. Cool. Still, if when caching the resolved path > we assume and, therefore, add the InstallFolder: prefix if it’s not already > there. After all, this is what the compiler is doing. Good to know, though. > **** > > **** > > *Heath Stewart***** > > VS Pro Deployment Experience, Microsoft > http://blogs.msdn.com/heaths**** > > **** > > *From:* Rob Mensching [mailto:[email protected] <[email protected]>] > > *Sent:* Wednesday, January 9, 2013 3:37 PM > *To:* Heath Stewart > *Cc:* Windows Installer XML toolset developer mailing list > *Subject:* Re: [WiX-devs] Merging directories at link time**** > > **** > > Up front, the "both" option is bad because if you remove a1.wixobj or > a2.wixobj your MSI still links but mysteriously one of the Properties > disappears.**** > > **** > > Yes, one could argue that is a cool feature but the subtle ways that can > go wrong do not offset the advantages. Also, if only identical Directory > rows are allowed to be duplicated then the subtle cool feature only can be > done with Directory elements. It feels sketchy all the way around and if we > really want to do said feature, I really want to dig into all the ways it > could go wrong.**** > > **** > > I'm not worried about anonymous, duplicate Directory rows being merged > because they can never cause the issue I point out above. You can't create > a reference an anonymous Directory (because you can't know it's id) so the > only thing that references the Directory is in the same section. No issue > with the removal of one of the .wixobj files above.**** > > **** > > Finally, I think you're missing a Simplified WiX feature "the implicit > InstallFolder root". Another example (because I think examples are most > helpful):**** > > **** > > a1.swr**** > > folder Id=A name=a**** > > file a1.txt**** > > **** > > The Simplified WiX compiler sees that "a" is not rooted in a well-known > root, so it roots it InstallFolder. So a.swr file ends up actually being:* > *** > > **** > > folder Id=InstallFolder extern=true**** > > folder Id=A name=a**** > > file a2.txt**** > > **** > > When creating .appx or .vsix packages they only support using > InstallFolder so it is very easy to create those packages and never have to > create a explictily named folder nor reference any folders. It's very > pretty.**** > > **** > > So, hopefully that clears up the confusion around what DirectoryRef is > used. In all my "a?.swr" examples, I beliee they've been rooted in > InstallFolder. If I misunderstood your point below then we'll just have to > try again. <smile/>**** > > > <snip/> > >
------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
_______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
