You can define the path relative to the build dir, or to the nant assemblies. Can't you?
I agree that doesn't need to be requirement (and it is not), which is why there is flexibility (and added power) in having the option to define extra tasks in either the build file, or the configuration. Heck, you could even specify that you want to have a new configuration that loads special tasks, set properties on the core tasks, and does other stuff if you want to. The configuration stuff is actually very flexible, and almost a build file unto itself, with a few special cases.
But in general, the build system configuration is meant to be pretty standard as part of the distribution. It is meant to help remove some of the complexities of integrating other source and resource compilers and abstract out a simpler usability for the project build file. But like I said, you have access to the source, to make change to the bindings in the config file, and write any type of build file you want; so go have fun...
The real questions here is how to balance the flexibility of the build system from the complexity of the build file. When things are split across multiple files, and are different across installations and machines, people can get confused and builds can fail.
----- Original Message ----- From: "Gary Feldman" <[EMAIL PROTECTED]>
>From: "Gert Driesen" <[EMAIL PROTECTED]> [re: using the config file to autoload the contrib and user extension directories]While that will ofcourse work, its definitely not the recommendedprocedure.
Why not?
It seems to me that if you're using a library of tasks, it makes more sense
to treat that as a configuration item, not a build item. Otherwise you
clutter up the build script with load tasks, which relate more to NAnt than
the thing being built. If you decide to use a common include file to
simplify that problem, then may wind up paying the expense of loading a
dozen .dlls when all you need for a specific build is just one. Either way,
you either have a hardwired path to the contrib directory that may not be
valid on all machines, or else you have to go through extra configuration
steps (e.g. defining an environment variable) anyway. Finally, it just
increases the learning curve for the build engineer who is often a junior
engineer, and not necessarily even a programmer. (No offense to the many
highly skilled build engineers, but they're the exception, not the rule.)
I can see that in some cases using loadtask may be better, but I don't see that it needs to be a hard and fast rule.
Gary
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
