From: Yves R. <yre...@sk...> - 2003-07-24 21:35:10
|
From reading the response posts I think I didn't make myself quiet = clear. First of all what I'm suggesting is only of interest (I think) for the = VS.NET solution/project camp. I have not found a library yet that = allows me to parse VS.NET solution (.sln) and/or project (.csproj) = files, and get an object model back from the parser. What is in that = object model? Well, possibly everything you can find out about a = solution or project via the related files (.sln/.csproj). How could = this affect the <solution> task? For starters it wouldn't have to do the = parsing of the solution/project files itself. Secondly, as a = consequence, the parsing code wouldn't be mingled with what the = <solution> task actually does. The object model could also provide for = a task that e.g. extracts the files included in a project and updates a = nant build file's <csc> task, essentially a partial one-way sync of the = build file and the VS.NET solution/project. Another use could be to = build VS.NET solution/project files via the object model (essentially = letting "something" else be the master of files, references, = interproject dependencies, etc...), which could maybe resolve your CVS = problem - conflicts in .csproj files due to teamdev - you[Erv Walter] = mention. Allowing the object model to save, in addition to the parsing, = could provide valuable in this case. So to resume, I'm talking about building a VS.NET solution/project = parser and object model (along the lines of what the VS.NET IDE = extensibility object "DTE" offers right now), and integrating that with = the <solution> task. |