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/>
On Wed, Jan 9, 2013 at 3:02 PM, Heath Stewart <hea...@outlook.com> wrote:
> Thank you. That clarifies the point.
>
> I was arguing for "both", but I see your point. however, how would
> anonymous IDs change that. Here's the paradox using the same authoring you
> have for p.wxs:
>
> You need to reference the parent directory. When it's declared like with
> "A", everything works as it does today. But if that directory was defined
> in swix (or even in twix if we allow for the new directory syntax like we
> discussed) without an ID, what would you link to? There's no symbol the
> setup dev would know about until the wixlib is linked. Adding an implicit
> row ID as we discussed wouldn't work since we couldn't know the row ID of
> the directory created in another wixlib (i.e. another process). If we
> require that any explicit reference requires the target ID to be defined
> (as you did), then how do we choose which instance of directory "A" defines
> and which reference "A"? Seems to me in that case you'd force setup devs to
> basically declare a wixlib just for directories (similar to our
> directories.wxs).
>
> I thought the idea was to simplify where you didn't really have to think
> about directories. Besides, if you're using twix and properly fragmenting
> your directories (like swix does automatically) and you do add a property
> as you've done, I'd argue that someone might intend for those both to be
> pulled in (much like merging of sections in the C/C++ linker - there are
> some tricks that people take advantage of for similar reasons).
>
>
>
> *Heath Stewart*
> Software Design Engineer
> Visual Studio, Microsoft
> http://blogs.msdn.com/heaths
>
>
> ------------------------------
> From: r...@robmensching.com
> Date: Wed, 9 Jan 2013 14:53:18 -0800
>
> Subject: Re: [WiX-devs] Merging directories at link time
> To: hea...@outlook.com
> CC: wix-devs@lists.sourceforge.net
>
> I'm just going to try and tackle point #1 in this part of the thread.
> Consider the following (and pretend I add all the close tags):
>
> a1.wxs
> <Fragment>
> <Property Id="A1" Value="ignored"/>
> <DirectoryRef Id="InstallFolder">
> <Directory Id="A" Name="a">
>
> a2.wxs
> <Fragment>
> <Property Id="A2" Value="ignored"/>
> <DirectoryRef Id="InstallFolder">
> <Directory Id="A" Name="a">
>
> p.wxs
> <Product>
> <Directory Id="TARGETDIR" Name="SourceDir">
> <Directory Id="InstallFolder" Name="My Product Name">
>
> <Feature>
> <Component Directory="A">
> <File Name="a.txt"/>
>
> If I compile and link all those together in my "p.msi" do I get properties
> for "A1" or "A2" or both? None of those options jive with what WiX does
> today and I would argue the linker should have errored saying "Directory
> with Id 'A' was duplicated".
>
> Agree?
>
>
>
> On Wed, Jan 9, 2013 at 2:14 PM, Heath Stewart <hea...@outlook.com> wrote:
>
>
> 1. That's just it. The first directory symbol - explicit ID or generated
> (since we're talking about linking multiple swix-generated wixlibs) - is
> treated as a Directory. Future dup symbols (keeping in mind the
> WixBackendCompiler will generate durable IDs for the same directory spec)
> are treated as a DirectoryRef. This is why I mention "partial" as opposed
> to "extern". "extern" always requires that someone defined the directory or
> else it doesn't work, where as "partial" (as in C#) is analogous to the
> situation I describe.
>
> 2. This is the WixDirectory table we discussed doing both in swix and
> twix. Twix already flattens the directory structure at one point so not
> only would swix store the authored directory spec, but twix would cache it
> as well. This helps verify that a dup symbol indeed references the same
> directory spec by checking the target dir, so we kow that a directory in
> swix InstallFolder:\a and in twix <Directory Id="InstallFolder"
> ...><Directory Name="a" ...> refer to the same thing. So the first parent
> DirectoryRef is really what ties these together. If users start declaring
> root directories in swix (the DirectoryRef before the colon) at different
> levels, they will get similar rows (duplicate in every way but the
> symbol/id) referring to the same target directory, but as long as these are
> parented to the same redirectable folder (like InstallFolder) it wouldn't
> matter. After all, that's how DEVDIV has been shipping (albeit with some
> extraneous type 51 CAs) for many years.
>
> 3. I don't follow. My point is that if you define the same file/registry
> key/value/or any non-directory resources in different wixlibs those should
> throw a dup symbol exception. That's a violation in the C/C++ linker. Given
> we follow that pattern pretty closely, as mentioned before I'd be treating
> all directories as "extern" in that the first one pulled in during link is
> treated as the defining symbol. All other resources would be an error (just
> like defining non-extern symbols in native code would err in the linker).
>
> 4. You had mentioned two files: a.swr and a'.swr that have the same
> directory specified a different way. Given one has an explicit ID and the
> other allows the WixBackendCompiler to generate an ID, if a.swr => a.wixlib
> and a'.swr => a'.wixlib, then two separate Directory rows are generated.
> This is the "pseudo-duplicate symbol" scenario I described above, but not a
> problem as long as they parent to the same root (ex: InstallFolder). I
> guess it's the a' that confuses me. Is this really a scenario of a.swr and
> b.swr, or is a'.swr modified from a.swr.
>
> Ultimately, authors still have to write decent code. I'm all for helping
> people from stumbling, but if you're defining a bunch of roots at different
> levels (all under some common root) you're going to run into problems. If
> nothing else, it would make for confusing product authoring. Merging
> directories based on their symbol coming in at link time (which both twix
> and wixlibs from swix would have available to the Linker) still
> fundamentally works like Directory and DirectoryRef now but can be done
> generically through the algorithm I described.
>
> *Heath Stewart*
> Software Design Engineer
> Visual Studio, Microsoft
> http://blogs.msdn.com/heaths
>
>
> ------------------------------
> From: r...@robmensching.com
> Date: Wed, 9 Jan 2013 12:09:09 -0800
>
> Subject: Re: [WiX-devs] Merging directories at link time
> To: hea...@outlook.com
> CC: wix-devs@lists.sourceforge.net
>
>
> 1. Given my point in a. I don't think all Directories should be treated as
> partial, only the Directories with an implicit Id (i.e. explicit
> Directory/@Id). If you "ignore the dup symbols" but allow multiple
> Directories to share Ids, then you essentially can have one DirectoryRef
> that pulls in multiple Fragments at the same time. That is quite a
> departure from the linker behavior today.
>
> 2. I don't understand this comment. Are you talking about changing the
> Simplified WiX FrontendCompiler to store more data? I don't follow.
>
> 3. For the user scenarios, I would consider each file being bulit
> independently since that is the hard case. Easy cases aren't terribly
> interesting other than as a basline so everyone is on the same page.
> <smile/>
>
> 4. I don't understand the scenario where you'd create a simple reference
> to something that doesn't have a symbol. I'm missing something in your last
> paragraph.
>
>
> On Wed, Jan 9, 2013 at 10:25 AM, Heath Stewart <hea...@outlook.com> wrote:
>
>
> 1. Correct, but the idea is to basically great them all as partial
> classes in C#. A bit different from eastern, but close enough. Also, the
> root directory preceding the colon is also a DirectoryRef.
> 2. Which is why I’ll store the directory path up till the first parent
> DirectoryRef into a new table ad e discussed internally. This will speed up
> some areas of binding and help resolve more true duplicates vs. fake duos
> (same I'd from different libs but different target directory).
>
>
> By “ignore the dup symbols” I’d still do all the same stuff as normal
> during linking but wouldn’t throw for the actual dup symbol string. I think
> that should mitigate the fragment issue.
>
> After consideration during our internal thread, I considered other
> elements but I don’t think it makes sense to. Dup files should throw, and
> registry doesn’t work the same. It gets fully resolved anyway so any duos
> should throw.
>
> What I don’t understand with the last bit is that by the time the
> authoring ends up in wixlibs the ids are assigned. Is a and a’ built to
> different wixlib or the same? That would help to fill in the information.
>
> Ultimately, I could only do full anonymous ids in twix for nested
> authoring. I can’t create a WixSimpleReferenceRow for something that
> doesn’t have a symbol especially if it’s in another wxlib. It would all be
> very inconsistent.
>
> - Heath from Windows Surface RT
>
> *From:* Rob Mensching
> *Sent:* January 9, 2013 9:22 AM
> *To:* hea...@outlook.com, Windows Installer XML toolset developer mailing
> list
> *Subject:* Re: [WiX-devs] Merging directories at link time
>
> A couple things about Simplified WiX since it's still new:
>
> 1. Simplified WiX will only create a DirectoryRef if a folder is marked
> "external=true". Otherwise a folder with an id will create a Directory with
> that explicit Id (although I've gone back and forth whether arch and lang
> should be appeneded automatically). I don't think that changes things but I
> wanted to make sure we are all on the same page.
>
> 2. Simplified WiX actually flattens the folder hierarchy before generating
> the Intermediate. That means you can't actually see all the duplicate
> anonymous folders in the Simplified WiX backend. Basically, it's the same
> sort of thing that I imagined the Traditional WiX Linker (or Binder?) would
> do to squish the anonymous Directories together. With this proposal we may
> need to reevaluate if that's still a good idea.
>
> This idea is growing on me. One issue and one question up front:
>
> a. Rows with implicit Ids could be merged. Rows with explicit Ids must
> collide and error in the Linker. If we don't do that then it will be
> "random" which Fragment gets pulled in if multiple Directory elements share
> an Id or we'd always have to pull in all Fragments with the matching
> Directory elements. That's a pretty big departure from where we are today
> and would really need to think through the implications if we changed it.
> Thus, I expect we'd have to denote rows with primary keys that were created
> implicitly (not a big deal, I expect).
>
> b. Do you see this concept of merging implicit Ids only working for
> Directories? What about RegistryKey? What about File, Shortcut, or other
> resources?
>
> At this point, I think the best thing would be to layout some user
> scenarios, including some pathological cases to ferret out error cases.
> I'm thinking showing a .swr(s) snippets plus the resulting rows that get
> created or errors shown would work.
>
> For example:
>
> -- a.swr
> folder id=A name=a
> file a.txt
>
> --a'.swr
> folder InstallFolder:\a
> file a.txt
>
> ==
> Error when seeing a.txt twice?
> -- or --
> Dir-(id),(parentfolder),(dirname)
> Dir: A,InstallFolder,a
> Dir: InstallFolder_a_hash,InstallFolder,a
> File-(id),(component),(filename)
> File: a.txt_hash,a.txt_hash,a.txt
> Comp-(id),(dirid),(keyfile)
> Comp: a.txt_hash,????,a.txt_hash
>
> Thinking through these scenarios help find stuff like the ???? above. What
> is the Directory Id for the Component if a.txt is allowed twice?
>
> I'm sure there are other cases to consider, can you send them?
>
>
>
> On Mon, Jan 7, 2013 at 2:59 PM, Heath Stewart <hea...@outlook.com> wrote:
>
> In an effort to support linking multiple simplified wix (swix) wixlibs to
> a tradition wix (twix) product package, there was a request for anonymous
> identifiers but apart from the conundrum of referring a symbol at link time
> that doesn’t yet exists (and wouldn’t until all information is available
> late in binding) I don’t think it’s actually necessary.****
> ** **
> The impetus is to support swix’s directory syntax for
> <DirectoryRef>:(\<Directory>(\<Directory>)) and have like-directories (say,
> root:\a and root:\a\b) merge to the same directory identifier. Currently in
> swix, the MSI identifiers are generated from the IdTypeConverter in the
> backend compiler similar to how delay-resolved fields work in twix. But
> swix uses a hierarchical model that is different from twix which passes
> through XML nodes to Parse*Element() method and those can create
> WixSimpleReference rows that merely specify the target table name and
> primary key (typical the sole ID field for that table). Changing that is a
> big departure for twix and would only work in a handful of cases
> (basically, for directories, components, and component resources) and for
> anything referenced in a Formattable field would still require a specified
> ID.****
> ** **
> But if the only requirement is that directories are merged, it seems to be
> – until the pattern in swix is used for twix, if ever – are smaller-scope
> change to resolve the directories (as twix does not, but I can store the
> result in a table such as WixDirectory to save time later) and ignore any
> duplicate symbols that resolve to the same path.****
> ** **
> In the example above with root:\a and root:\a\b, a would end up with the
> same stable identifier. We’ll assume “root” is defined in twix since in
> swix it’s still a DirectoryRef. As we link “a” the first time, nothing
> changes. But when we try to link “a” the second time we see they refer to
> the same target (install) directory so we don’t raise a DuplicateSymbol
> error and just ignore it. “b” already has a ref to the ID for “a” as would
> any Formattable column types.****
> ** **
> Does anyone see any problems with this approach?****
> ** **
> ** **
> *Heath Stewart*****
> VS Pro Deployment Experience, Microsoft
> http://blogs.msdn.com/heaths****
> ** **
>
>
> ------------------------------------------------------------------------------
> 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_122412
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
>
>
>
------------------------------------------------------------------------------
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
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
