Thank you. That clarifies the point. I was arguing for "both", but I see your point. however, how would anonymous IDs change that. Here's the paradox using the same authoring you have for p.wxs: You need to reference the parent directory. When it's declared like with "A", everything works as it does today. But if that directory was defined in swix (or even in twix if we allow for the new directory syntax like we discussed) without an ID, what would you link to? There's no symbol the setup dev would know about until the wixlib is linked. Adding an implicit row ID as we discussed wouldn't work since we couldn't know the row ID of the directory created in another wixlib (i.e. another process). If we require that any explicit reference requires the target ID to be defined (as you did), then how do we choose which instance of directory "A" defines and which reference "A"? Seems to me in that case you'd force setup devs to basically declare a wixlib just for directories (similar to our directories.wxs). I thought the idea was to simplify where you didn't really have to think about directories. Besides, if you're using twix and properly fragmenting your directories (like swix does automatically) and you do add a property as you've done, I'd argue that someone might intend for those both to be pulled in (much like merging of sections in the C/C++ linker - there are some tricks that people take advantage of for similar reasons).
Heath Stewart Software Design Engineer Visual Studio, Microsoft http://blogs.msdn.com/heaths From: r...@robmensching.com Date: Wed, 9 Jan 2013 14:53:18 -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 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: 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.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.swrfolder id=A name=a file a.txt --a'.swrfolder InstallFolder:\a file a.txt ==Error when seeing a.txt twice?-- or --Dir-(id),(parentfolder),(dirname) Dir: A,InstallFolder,aDir: InstallFolder_a_hash,InstallFolder,aFile-(id),(component),(filename)File: a.txt_hash,a.txt_hash,a.txtComp-(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 StewartVS 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
