Hi,
I'd like to start working on improved support for embedded and linked
resource (of which some features have been introduced in .NET 2.0) :
AssemblyLinker (<al>):
----------------------
- Support specific identifiers for embedded and linked resources
- Support "public|private" accessibility for embedded and linked resources
(default is public)
- Support "target" for linked resources (we just need to pass this on to
al.exe)
Compiler tasks (<vbc>/<csc>/<jsc>/<vjc>):
-----------------------------------------
- Support specific identifiers for embedded and linked resources
- Support "public|private" accessibility for embedded and linked resources
[.NET 2.0]
- Support "target" for linked resources (in this case, we need to copy the
linked resource to the "target" path ourselves, as the compilers do not
support this directly) [.NET 2.0]
Questions:
----------
<al>
1. Should we continue to support scanning for resource files (using
patterns) ?
If we also support patterns, should we support explicitly named
resource files
and patterns in the same element.
For example:
<embeddedresources>
<include name="**/*.txt" />
<resource file="whatever.doc" identifier="somedoc"
accessibility="Private" />
</embeddresources>
If we decide to add support for scanning/pattern matching to
<embeddedresources> / <linkedresources>,
then should we have an "accessibility" attribute on the <include>
(or whatever we call it) element, or should
we have an "accessibility" attribute on the <embeddedresources> /
<linkedresources> ?
Or should we have an "accessibility" attribute on both; meaning,
allow the <include>
and <resource> elements to override the accessibility set on the
<embeddedresources>
/ <linkedresources> (which serve as a default value) ?
<al> and compiler tasks
1. Should we combine pattern matching for files and explicitly specified
resources in the same element ?
Should we deprecate the <resources> elements on the compiler tasks,
and combine pattern matching
and explicit lists of resources in one parent element ?
For more info, see <al> question #1.
2. Should we have a "dir" or "basedir" attribute on the <embeddedresources>
/ <linkedresources> element ?
Relative paths specified in the "file" attribute of embedded/linked
resources, would then
be considered to be relative to this directory.
If we decide not have this attribute, then how (using what base
directory) should we resovle these relative paths to full paths ?
If we decide to add scanning support to the <embeddedresources> /
<linkedresources> elements, then we should definitely
have a dir/basedir attribute.
3. Is it ok to consider the "target" path, if not specified as an absolute
path, to be relative to the output file?
Note: this only applies to linked resources.
For example:
<linkedresources>
<resource file="whatever.doc" identifier="somedoc"
accessibility="Private" target="somedoc" />
</linkedresources>
4. Where do we put the logic of converting relative paths to absolute paths
?
5. Do we use a ResourceAccessibility enum for the "accessibility" attribute
?
Please don't hesitate to correct me where necessary or propose a better
solution.
Any feedback is welcome.
Gert
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
