Hi, > 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. 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. > We should start it off as a simple wrapper for MSBuild.exe. I > think it should be closer to the <nant> task than the <solution> task. > > I think we should add support for : > > - properties (nested element with collection, similar to <nant> task) <arg> is already present. To add property just write <arg>/p:name=value</arg> No problem to add something more similar to <nant> task though. > - target(s) (string attribute or nested element with > collection of targets > ?) true. forgot to it :) > - logger (string attribute, or nested element with class and > assembly attribute, and parameters collection ?) I'd like to add XmlLogger to our code (that one from ccnet, if they will borrow it to us, or write ours own), since msbuild comes with only console logger. > - verbosity (enum attribute, do we let this coexist with our "verbose" > attribute ?) I mirror Verbose property (nant -v) into that. I still do not grok nant's verbosity system (you remember I have alot complaints about it some time ago). But I believe we could somehow place both worlds together in this respect. > Optional: > > -noconsolelogger (bool attribute) > -consoleloggerparameters (nested element, containing collection of > parameters) > -noautoresponse (bool attribute) > -validate (nested element, as it should have an on/off switch > and a way to specify a schema file) Ok, no problems with those. > Martin: don't mean to sound negative about the work you've > done. Thanks for starting with this !! :-) > 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). Martin ------------------------------------------------------- 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_id=7637&alloc_id=16865&op=click _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
