Re: 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.
But the ID generation is durable, such that “Foo” in both cases is something
like Foo_InstallFolder_hash, so when you link a.wixlib and b.wixlib together
you get a duplicate symbol error. That’s why I’m recommending the merge
strategy that is akin to C# partial classes.
But it seems from your last inline statement you’re in agreement, correct? So
the only open issue I see is what you brought up before, that if in twix two
fragments that define the same directory but have different other content (like
below), we should, what, fail or take them? I’m recommending linking them in.
The C/C++ linker does this though it’s not touted as a feature.
<Fragment>
<Property Id=”A” …/>
<Directory Name=”Foo” …/>
<Fragment>
<Property Id=”B” …/>
<Directory Name=”Foo” …/>
As it stands today, linking those would throw the duplicate symbol error. So no
one could be accidentally doing that today. With the change I’m recommending,
new authoring would make it possible but 1) this isn’t possible in swix, and 2)
it’s doubtful anyone would do this in twix and, if merging directories is
documented (as I plan), then they got what they asked for.
Heath Stewart
VS Pro Deployment Experience, Microsoft
http://blogs.msdn.com/heaths
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Tuesday, January 15, 2013 9:24 PM
To: Heath Stewart
Cc: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] Merging directories at link time
inline
On Tue, Jan 15, 2013 at 3:42 PM, Heath Stewart <hea...@outlook.com
<mailto:hea...@outlook.com> > 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:r...@robmensching.com
<mailto:r...@robmensching.com> ]
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 <hea...@outlook.com
<mailto:hea...@outlook.com> > 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:hea...@outlook.com <mailto:hea...@outlook.com> ]
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:r...@robmensching.com]
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 Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
