----- Original Message ----- From: "James Geurts" <[EMAIL PROTECTED]> To: "'Craig Neuwirt'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, March 11, 2004 8:45 PM Subject: [NAntC-Dev] RE: NAnt conflict with NAntContrib MSI Task
> Thanks Craig, > > I am including the list on this reply so that they have a record of this > behavior... > > Jim > > -----Original Message----- > From: Craig Neuwirt [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 11, 2004 2:38 PM > To: James Geurts > Cc: [EMAIL PROTECTED] > Subject: NAnt conflict with NAntContrib MSI Task > > Hello James, > > I identified the problem described in the previous mail. Just so you > know, the latest version of NAnt can possibly cause existing NAnt builds > that use NAntContrib to fail. In my situation I had a target that loaded > the NAntContrib using the following > > <loadtasks path="${contrib.dir}\nantcontrib\bin"/> > Prior to the recent changes in NAnt, this would have loaded the tasks from > all dll that ended with .Tasks. However, the new build does not filter the > dll so all of them are loaded. This behaviour has indeed recently changed. It did not make any sense to force third party tasks developers to use a *Tasks suffix for their assemblies. Sorry if this caused problems for you. The <loadtasks> will also probably be renamed to <load-extensions> soon (if you can come up with something better, please let me know), and will no longer support the 'path' attribute. Gert ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
