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
