Hi,
I've made an inventory of issue we need to tackle better soon than late,
some of them have been discussed before, but I think its best to bring them
up again in order to have an agreement (and solution) for all issues :
1. Resgen can be used to compile multiple resource files at once, and we
already support this. However, we do not have a way to specifiy the output
file for each individual resource file. This is not possible right now, as
we use a fileset to specify the input resources, so the number of input
files is not fixed. In some cases, using files matching a certain pattern is
great, but in cases like this here, its a major PITA. Allowing multiple
input files, and corresponding output files in a single run of the resgen
task would be very good for the performance of the solution task ... Are
we gonna support this ? If we do : how ?
2. We should support explicit manifest resource names to be specified for
individual resources that need to be embedded/linked (using the compiler or
al tasks)
3. MS.NET 2.0 has new features related to resource files that will be quite
a challenge to us :
- resgen has a new option (/str) with which you can instruct resgen to
create a strongly-typed resource class, with this option you can set the
programming langugage, namespace, class name and file name (for the
generated resource class). How will we support this ? Will we also need to
support this in the compiler tasks, or do we expect users to use another
task (resgen?) to generate the strongly-typed resource classes first, and
then use the compiler tasks ?
- .NET 2.0 allows a access modfier to be specified for embedded and linked
resources. Again, this doesn't work very wel in combination with a fileset,
as you would not be able to set access modifiers on individual files.
Now, the question is : how do we proceed on all this ? I'd suggest we all
have a closer look, and please speak up if you have any ideas, remarks, ...
I don't think we should underestimate the impact of all this, but we cannot
avoid this ...
Gert
- Original Message -
From: Gert Driesen [EMAIL PROTECTED]
To: Ian MacLean [EMAIL PROTECTED]
Cc: Nant-Developers (E-Mail) [EMAIL PROTECTED]
Sent: Friday, July 23, 2004 12:09 PM
Subject: Re: [nant-dev] ResourceFileSet
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]
Cc: Nant-Developers (E-Mail) [EMAIL PROTECTED]
Sent: Tuesday, July 27, 2004 10:16 AM
Subject: Re: [nant-dev] ResourceFileSet
Gert Driesen wrote:
- Original Message -
From: Ian MacLean [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]
Cc: Nant-Developers (E-Mail) [EMAIL PROTECTED]
Sent: Saturday, July 24, 2004 7:08 AM
Subject: Re: [nant-dev] ResourceFileSet
First off sorry for top-posting but this thread is getting too long to
reply inline. I agree that having a profusion of resource related
elements isn't a good thing so lets go with the augmented fileset
rather
than a dedicated namedresources element.
We might have one more option : add an embeddedresources element,
which
supports a nested fileset and a nested array of resource element,
meaning
something like this :
csc
embeddedresources
files basedir=... (not sure about the files name though)
include name=... /
include name=... /
/files
resource file=.. name= / (files name would be relative
to
project base directory)
resource file=.. name= /
/embeddedresources
/csc
I do think its less confusing, but it is ofcourse (a lot) more verbose
...
Not sure I really like it myself ...
yeah - its a bit too verbose for my liking and not necessarily any less
confusing.
No, I think I agree ...
What will we do with the accessibility modifier that can be specified
for
resources files in .NET 2.0 ? Should we add a accessibility (any
better
name for this ?) attribute to the (Resource/ResX/Whatever)FileSet (we
can't
have one on the individual include elements, that's for sure) and to the
resource element ? Guess so, right ?
I guess so. I don't know what the accessibility modifier does. I should
go check it I suppose.
Need to check it myself ;-) We also need to have a look at the impact of
the fact that resgen now supports creating strong named resource classes
(or something like that), which is used a lot by VS.NET.
but if we
still to the old plan then we could just rename the current
ResourceFileSet to ResXFileSet (although it handles more than just resx
files) and use that for the compiler tasks, and add a new
ResourceFileSet
for the al task, right ?
Yeah that sounds fine.
ok, but I guess we first need to have a look at the new /str resgen option
(see above), and see how we can support that.
resgen will change to using a regular fileset instead of a
ResourceFileSet. Incidentally why does it use ResourceFileSet now ? Is
it just for easier assignment from the compiler tasks ?
Its not easier at all, so I
