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 really have no clue ...
>
>
>
hmm - pretty sure I wrote at least some of that code and I have no idea
either. Well - if we don't need the ResourceFileset there then lets
change it to FileSet.

ok

Gert


------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers




------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to