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.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
