First, just to get this out of the way, the FrontendCompiler doesn't create objects like that today (that I'm aware of). I also don't think it should. However, unless you disagree, I do not think this is really pertinent to the feature (aka: we can burn this bridge later)
Second, I basically agree with you. We don't try to mitigate it. Honestly, the more I've thought about it, the more I've come around to thinking that the scenario you described above is actually the correct design (although I generate the anonymous rows' ids differently <smile/>). Here's why: Let's say you want a Type 51 custom action in your Traditional WiX authoring to only change the path for "bar.dll" and "baz.dll" but *not*"foo.dll". Based on your authoring example, and the explicit use of CommonExtensions as a named folder, that is possible. <SetProperty Id="CommonExtensions" Value="[SOMEPROPERTY]\Foo" After="CostFinalize" /> Instead, if you do what I was thinking (and what Simplified WiX FrontendCompiler does right now), then "foo.dll" gets sucked into the named "CommonExtensions" folder. Now, it may be a bug when someone finds out that "foo.dll" didn't move correctly but it's pretty easy to seen in the authoring why. So, fundamentally, I'm not looking to mitigating things. I'm now just looking for the user scenarios/test cases to work through all the complicated examples that can happen to make sure there is nothing screwy going on and error cases can be handled reasonably. Basically, we are talkinga bout automagically merging Directory rows in the Linker. That's something we've never done in WiX. Want to walk it through. On Wed, Jan 9, 2013 at 3:27 PM, Heath Stewart <hea...@outlook.com> wrote: > I get that by the time it gets to the BackendCompiler it's "flattened" > (doesn't seem like the right word, but I'll go with it :)) but we'd create > the objects - as we would in twix - in the FrontendCompiler and persist > those to rows. The symbol column would be resolved by the existing > DelayResolvedField code that is similar to what we use in twix (which I > thought about using in twix at one point, but it happens to late after link > to make sure we pull in all the right reference, hence the paradox). > > But, yes, you are right in your example. > > I know what you're saying about the more complicated examples. I guess > what I'm arguing for / wanting feedback on is how much we should worry > about it. > > In good product authoring, I would expect there to be very few roots. For > most products, this is probably only InstallFolder. In that case, the > simple example we've been throwing around (like the one below) works fine. > You might end up with a few pseudo-dup rows but they both parent to > InstallFolder so all is well. > > If a setup dev defines additional roots under InstallFolder, you may end > up with more pseudo-dup rows. Consider the following: > > [a.swr] > folder name="InstallFolder:\CommonExtensions" > file source="foo.dll" > > [b.swr] > folder id="CommonExtensions" name="InstallFolder:\CommonExtensions" > file source="bar.dll" > > [c.swr] > folder name="CommonExtensions:\B" > file source="baz.dll" > > Ignoring the definition of InstallFolder and its parents, I see three > Directory rows here: > > CommonExtensions_InstallFolder_<hash>, InstallFolder, CommonExtensions > CommonExtensions, InstallFolder, CommonExtensions > B_CommonExtensions_<hash>, CommonExtensions, B > > And while it should all work out (assuming there are no type 51 CAs trying > to set one of those elsewhere) during installation, it seems like setup > authors are complicating their work by having various ways to reference the > same directory. I know you've lived it. :) > > So how much do we try to mitigate this issue? > > > > *Heath Stewart* > Software Design Engineer > Visual Studio, Microsoft > http://blogs.msdn.com/heaths > > > ------------------------------ > From: r...@robmensching.com > Date: Wed, 9 Jan 2013 15:07:17 -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 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
