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 <[email protected]> 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:* [email protected], 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 <[email protected]> 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 >> [email protected] >> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
