> I'm curious as to why these arent considered "DotNetTasks"
Basically I'm trying to cut up the tasks so that people who don't want them (ie, me :) can use those task names for their own tasks. I'm using a <cc>, <lib> and <link> tasks that work with four different platforms using a number of predefined properties for a custom project. This is a sympton of the larger problem of task names conflicting. We could "import" task assemblies into XML namespaces but their format isn't exactly pretty. Another solution is by using an <import> task that replaces the <taskdef> task. It would be used like this: <import assembly="NAnt.DotNetTasks.dll" prefix="dotnet-"/> You would then use the tasks from this assembly as follows: <dotnet-csc/> Omitting the prefix attribute just brings the tasks into the default namespace. The tasks in NAnt.Core would always be in the default namespace. Consider them "reserved" words. I'd be interested in hearing opinions of this. It would solve the task name collisions. Another cool thing would be that if your project used custom tasks that most people didn't have you might use: <import assembly="http://nant.sf.net/tasks/release/1.3/CustomTasks.dll"/> Of course you could also just build those nant tasks as part of the project's build process (like how nant builds the documenter assembly on demand). In anycase there is a now a NAnt.VisualCppTasks project in CVS. To use the tasks just build a release configuration of nant. nant release test ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
