RE: [nant-dev] Solution/Project Parser

[Erv Walter]

I'm not sure I understand your proposed change.  Can you clarify?   There are 2 camps (and now possibly a third).  The difference between the camps is personal preference, really.   One camp is the group of people who find dually managing build files and project/solution files undesirable (a completely valid point of view).  This group of people would want the <solution> task to be as magic as possible since the idea is that the .sln and it's referenced project files contain all the pieces of information needed to correctly build stuff.  Are you suggesting that things should be somehow broken out more from that end user's point of view?  Again, I could use some clarification on exactly what you're proposing and what it would make build files look like (sorry for being slow on the uptake).   For the record, I'm in the camp that prefers the clean, explicit nature of NAnt build files using <csc> and related tasks directly.  I think that the VS.NET solutions and projects are messy, poorly designed by Microsoft, and unmanageable in large team development situations.  I have daily CVS conflicts with the .csproj files I use to the point that we're considering removing them from CVS completely and making them personal tools only.  We already have removed the .sln files from CVS.  We have since configured VS.NET to use NAnt to build anyway, so the .csproj files have become little more than the holders of file lists and no longer the holder of build settings.   From: Yves Reynhout [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: [nant-dev] Solution/Project Parser Hi,   I've been following (though I should admit not very actively using) NAnt for a while now (about 1200 nant posts in my inbox) .  Especially, not being able to handle the VS.NET "solution" concept was something that bothered me (well, let me rephrase: not handled elegantly).  Ofcourse, it all depends on your focal point, meaning if you don't use VS.NET, you probably couldn't care less about the "solution" concept.  And then it was Matthew Mastracci I believe (correct me if I'm wrong) that introduced the <solution> task into NAnt.  Unfortunatly, I'm not quiet happy with its current implementation, because there's no clear separation between the "solution/project" as data (the content of the .sln and .*prj files) and the "solution" task itself.  The current implementation provides an object model for its current purpose, namely the "solution" task.  Wouldn't it be more usefull to build upon a common representation (read object model) of the VS.NET solutions and projects and re-use that representation in (for now) the solution task.  Maybe there are other uses for the common representation (read other tasks) of the VS.NET solutions/projects.  In an attempt to fill what I feel is a void I started work on a VS.NET Project and Solution Parser/Object model.  My question to the NAnt team, and probably Matthew Mastracci in particular, if they are interested in this parser (which is in no way finished).  I realize this could cause refactoring in the area of the "solution" task and since NAnt will come out with releases on a more regular basis, I'll let you guys be the judge of what I proposed.   To Matthew Mastracci I'd like to say: "Thank you for bringing the 'solution' task to the table.".