I'm just going to tackle point #2 in this part of the thread. My point was
that I don't think you can create the WixDirectory table in the Simplified
WiX BackendCompiler because the folder objects were flattened during
FrontendCompiler. In other words:
a1.swr
folder Id=A name=a
file a1.txt
a2.swr
folder a
file a2.txt
If compiled together, the BackedCompiler would see objects that made it
look like the authoring was actually done this way (i.e. the
FrontendCompiler does the following to the two files):
folder Id=InstallFolder extern=true
folder Id=A name=a
file a1.txt
file a2.txt
The anonymous folder from a2.swr was nuked during the Resolve() of
FrontendCompiler because an explicitly id'd folder "A" resolved to the same
path. That means, today, the BackendCompiler would never know that there
was a folder named "a" in a2.swr.
My idea for anonymous rows in Traditional WiX came from this behavior in
Simplified WiX.
All that said, I belive understand your proposal to have these things end
up in separate trees. In other words, the result of the FrontendCompiler
given my example files would be more like:
folder Id=InstallFolder extern=true
folder Id=A name=a
file a1.txt
folder Id=InstallFolder_a_hash name=a
file a2.txt
Right?
I'm not against your idea (I'm starting to like some aspects of it) but I'm
asking if you could enumerate some the more complex user scenarios so we
can see how they behave and what the error cases are (to fully convince me
the aspects are good and the bad aspects can be handled as error
conditions).
Or consider it writing the test cases to ensure the feature works. <smile/>
On Wed, Jan 9, 2013 at 2:53 PM, Rob Mensching <r...@robmensching.com> wrote:
> 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
