Ian,
Thanks for your reply. I understand the mechanics "integrating" my
tasks to the ${nant.location}, but it's beside the point. It seems to
me it's wrong-headed to deprecate a means of extensibility. It means
that anyone who upgrades NAnt HAS TO do something(s) extra in order to
re-drop their tasks into ${nant.location}, as opposed to just keeping
our customizations in their own place(s) and letting taskdef to its
thing on project-by-project basis. (eg: What if I have diffent versions
of MyCustomTasks.dll to use with diverse projects?)
Basically, there's no gain in not having it in the core, just a loss.
It's wonderful magic that dropping *tasks.dll in ${nant.location} makes
things go, but it shouldn't be the only means of extensibility, as it
forces users to jump through hoops when they upgrade Nant.
> Jean,
> the reason its in nantcontrib is because its deprecated. To add new
> tasks all you need to is drop the new task assembly in the
> same folder
> as nant and it will *automatically* find all the tasks in it. See the
> FAQ [1] and the "Writing a custom NAnt task " turorial[2] on
> the wiki [3]
> ---8<---
> Isn't part of
> > the Ant spec anyway? It's even part of the examples in Nant, which
> > crash, obviously.
>
> we should probably update the examples in that case.
>
Actually, in v. 0.8.x, the UserTask example HAS been updated to lose the
reference to <taskdef /> and to copy the usertask.dll into
${Nant.Location}. One less thing to do ...:)
/jean
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
