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
