After giving it a little more thought (it is actually still very early here,
so I'm sure if that means anything), I think we actually have multiple
options :
- use Ian's patch
- create an AssemblyReferences (?) class (deriving from FileSet ?)
- create an AssemblyReference class with matching collection class
- extend the current FileSet class with an assembly child element (which
would not support patterns of course)
<references>
<includes name="..." />
<assembly file="System.Web.dll" />
<assembly name="log4net, Version=1.2.0.4444, Culture=neutral,
PublicKeyToken=0038abc9deabfle5" />
</references>
We could somehow also support having references using (fully qualified)
assembly names (NAnt.Core, Version=..., Culture= ..., PublicKeyToken=....),
but I have no idea how to resolve a fully qualified assembly name to it's
file path (anyone ?)
IAn's patch would only deal with the compiler tasks, but wouldn't it also be
useful for other tasks that currently use a FileSet to resolve assembly
references, for example ndoc, asminfo, nunit, ...
Would this also be useful for non-.NET related tasks, eg. for copying an
assembly to another directory ?
Gert
----- Original Message -----
From: "Matthew Mastracci" <[EMAIL PROTECTED]>
To: "Ian MacLean" <[EMAIL PROTECTED]>
Cc: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>; "Gert Driesen"
<[EMAIL PROTECTED]>; "NAnt Developers"
<[EMAIL PROTECTED]>
Sent: Monday, September 08, 2003 5:40 AM
Subject: Re: [nant-dev] [PATCH] New fileset option "fromframework"
> Just as an alternate suggestion, why not just have a framework fileset
> building task separate from the fileset task? It seems like adding
> specific functionality (through I agree this is a borderline case) to
> the task might be overloading a fairly concise task with something not
> as specific.
>
> Perhaps:
>
> <fileset>
> ...
> </fileset>
>
> <frameworkfileset>
> ...
> </frameworkfileset>
>
> ?
>
> Matt.
>
> On Sun, 2003-09-07 at 19:34, Ian MacLean wrote:
> > Jaroslaw Kowalski wrote:
> >
> > >After some thougths, I think that the whole FrameworkInfo management
doesn't
> > >belong in NAnt.Core and therefore FileSets shouldn't rely on framework
> > >concept at all.
> > >
> > >
> > >
> > I think FrameworkInfo does belong in NAnt.Core simply becuase its such a
> > major part of the tool. But you're right you shouldn't have to have a
> > currentframework to run nant. Its possible to not have one if you for
> > example don't have the SDK installed - only the runtime. In that case
> > nant would run and all the copy, move and other non .Net tasks will run
> > fine. csc etc will obviouly not work.
> >
> > >Am I right? Can the concept of frameworks be useful for anything other
than
> > >dotnet ? And how is it possible not to have a currentframework ?
> > >
> > >
> > >
> > Its also useful for running managed applications on mono where we
> > automatically run 'mono foo.exe' rather than trying to execute foo.exe
> > as a standalone executable.
> >
> > Ian
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > nant-developers mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/nant-developers
> --
> Matthew Mastracci <[EMAIL PROTECTED]>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> nant-developers mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-developers
>
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
