>-----Original Message----- >From: Ian MacLean [mailto:[EMAIL PROTECTED] >Sent: Friday, December 9, 2005 09:06 AM >To: 'Martin Aliger' >Cc: ''Gert Driesen'', ''Gert Driesen'', ''! nant'' >Subject: Re: [nant-dev] need VS 2005 solution task support > >Martin Aliger wrote: > >>>I don't think we need to make <solution> task compatibility a >>>goal here. >>> >>> >> >>I was thinking same, but first I wanted to use msbuild, I found myself in >>situation where <solution> is used today. Even that msbuild is quite general >>system, we, nant users, will call it mainly to compile vs2005 solutions. So >>I rethink it, and it makes some sense to me. >> >> >> >>>Creating a solution on the fly is not something we should >>>support, as you need to make a bunch of assumptions anyway >>>(dependencies, platform, ...). >>> >>> >> >>In fact, this was first issue I come around, when writing msbuild wrapper >>task. Thats why I rethinked implementation. If you find more appropriate, we >>could make <msbuild> task as "direct" wrapper and make another task,say >><vs2005> or <msbuild-solution>, which could do those additional wrapping. >> >> >This sounds like a good compromise. <msbuild> gives you full control of >the msbuild commandline while <msbuild-solution> provides a nice upgrade >path for vs2003 <solution> task users.
Yes, I agree that this is the right thing to do. > >>Good think about this on-the-fly solution creation is, that msbuild imply >>dependences and project compile order from it. Exacly what our <solution> do >>when we fed it with project fileset. Sure - there are assumption, but I >>beleive they could be made configurable where appropriate. >> >> >> >so it sounds like there is definately a place for <solution> like >functionality in an msbuild wrapping task. > >> >> >> >>>About namespace/packaging: would it be ok to add it to >>>NAntContrib first, and move it to NAnt once it has stabilized >>>? This is our policy for all new tasks. >>> >>> >> >>np. I do not use NAntContrib currently, but no problems with relocating to >>another project. It is quite stand-alone task (depending on just >>ExternalProgramBase). >> >> >Putting it NAntContrib first is the correct policy decision but I >suspect we'll have some demand to move it into main fairly soon - vs2005 >support for <solution> has been one of the most requested features. I think the "pure" msbuild wrapper task should more easily (rapidly) find its way to NAnt, as its built upon a stable command line interface. If you look at the features requested by users of the current <solution> task, the msbuild-based <solution> task might actually be better off in NAntContrib as it allows more custom tailoring (and you'll find less resistance to breaking changes) while tasks in NAnt should be more stable and only contain generally useful features. Note: I'm not saying the msbuild-based <solution> task is not generally useful. >Thanks for starting this Martin - I'm sure there will be many happy ><solution> task users. Definitely agree with this ! Gert ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
