Re: [nant-dev] Solution/Project Parser
I've developed and am using a NAnt custom task vsnetsln that separates the sln and the proj as follows: x calls separate vsnetproj task for each project found in sln--and allows specifying a default .build file for use on a per-proj basis, thus separating project-wide .build file from per-project build file(s) x like solution, you can pass in *proj files only instead of a .sln (which I tend to prefer). I can post this to a NAnt contrib if anyone's interested. / /br Yves Reynhout [EMAIL PROTECTED] wrote: 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 buildupon a common representation (read object model) of the VS.NET solutions andprojectsand re-use that representation in (for now) the solution task. Maybe there are otheruses for the commonrepresentation (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 thiscould 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.". - - - - - - - - - - - - - - - - -Buc Rogers[EMAIL PROTECTED]
RE: [nant-dev] Solution/Project Parser
Title: Message Hello Yves, Have you looked at the parsing logic and object model in Slingshot, a tool and task included in NAntContrib? Although it is considered 'obsolete' and does not support Framework v1.1, it seems like a clean starting point. Best regards, Bernard -Original Message-From: Yves Reynhout [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 11:35 PMTo: [EMAIL PROTECTED]Subject: Re: [nant-dev] Solution/Project Parser 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 filesitself. Secondly, as a consequence, the parsing code wouldn't be mingled with what the solutiontask actually does. The object model could also provide for a task that e.g. extracts the files included in a project andupdates 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 buildinga 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.
Re: [nant-dev] Solution/Project Parser
Perhaps it might be better to design an .xsd and use the automatic XML deserialization routines. I've found that this way is much cleaner than the methods used in the current solution and slingshot tasks. Bernard Vander Beken wrote: Hello Yves, Have you looked at the parsing logic and object model in Slingshot, a tool and task included in NAntContrib? Although it is considered 'obsolete' and does not support Framework v1.1, it seems like a clean starting point. Best regards, Bernard -Original Message- *From:* Yves Reynhout [mailto:[EMAIL PROTECTED] *Sent:* Thursday, July 24, 2003 11:35 PM *To:* [EMAIL PROTECTED] *Subject:* Re: [nant-dev] Solution/Project Parser 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. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Solution/Project Parser
Matthew Mastracci wrote: Perhaps it might be better to design an .xsd and use the automatic XML deserialization routines. I've found that this way is much cleaner than the methods used in the current solution and slingshot tasks. Using the xml de-/serialization way is fine for .csproj, but I don't see this happening for .sln. Also, xmlde/serialization tends toset some requirements (get/setcombination, ...) which are not always desirable. But it's definitly something I'll look into. I do plan to put an xmlschema on top of the object model. Bernard Vander Bekenwrote: Hello Yves,Have you looked at the parsing logic and object model in Slingshot, atool and task included in NAntContrib?Although it is considered 'obsolete' and does not support Frameworkv1.1, it seems like a clean starting point.Best regards,Bernard Thanx, I'll have a look at it.
RE: [nant-dev] Solution/Project Parser
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. Onecamp 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 listsand no longer the holder of build settings. From: Yves Reynhout [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 22, 2003 5:02 PMTo: [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 buildupon a common representation (read object model) of the VS.NET solutions andprojectsand re-use that representation in (for now) the solution task. Maybe there are otheruses for the commonrepresentation (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 thiscould 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.".
Re: [nant-dev] Solution/Project Parser
No problem. I'm all for refactoring the solution task. It's not an elegant solution for what it accomplishes. My overall goal for the solution task is to be able to point it at either a solution or a group of projects and have them built in the correct order, with outputs identical to how VS.NET would have built them. I'm interested to hear more of your ideas. I'm not particularly attached to any part of my implementation. :) If you do start work on cleaning up the object model, perhaps try to envision how the solution task could use other NAnt tasks, rather than the executables directly. I personally don't use the .sln parsing facilities of the solution task, but rather the fileset list of projects to reconstruct the solution. Yves Reynhout wrote: 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.. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Solution/Project Parser
I'm with you on the .sln thing. We were getting daily conflicts on the .sln file, so I ended up checking it in as a binary file so that it wouldn't merge. .csproj files seems to be adequate for our needs. They occasionally conflict, but not enough so far to annoy us out of using them (yet). I'm also getting close to wanting to use NAnt completely within the build process. The locking of files by VS.NET is getting to be such a pain - I had to write an add-in for VS.NET that would search all the open file handles for the currently-being-built assembly and close it. :) It might just be easier (and faster?) to run the NAnt build each time instead. Erv Walter wrote: 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.. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Solution/Project Parser
Every developer (the main dev team has about 8 people) builds directly with nant everytime (one of my coworkers came up with the idea to add a custom tool to vs.net that fires nant for the project and puts the nant output in the vs.net output window. nifty!). How does one go about integrating NAnt with VS.NET? Is anybody willing to share what they user and/or how they did it? : Aaron Jensen : [EMAIL PROTECTED] : 800.237.6335 ext 421 : Financial Profiles : www.profiles.com --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Solution/Project Parser
Does VS.NET save all of your files before doing a build, or do you have to manually save them? Bill Conroy wrote: My whole team does this all too. Here is the writeup I gave out a while back to the OT list on how to do this: Here are the steps I used to integrate[note I do not address keeping a csproj in sync with the build file, but I could] Do this once: 1. Add an external tool Title: Nant (Current Project) Command: nant -- assuming nant is in your path. Arguments: [I have nothing here, I use the default target in VS.NET] Init Dir: $(ProjectDir) I check Use Output Dir. This gives you output lines which are context sensitive for the file, line of the error/warning. 2. Add an external tool Title: Nant (Solution) Command: nant -- assuming nant is in your path. Arguments: [I have nothing here, I use the default target in VS.NET] Init Dir: $(SolutionDir) Check Output Dir. 3. I have hooked up F7 to Nant (Current Project), and Shift-F7 to Nant (Solution) through the Keyboard settings in Tools|Options. For each project you want to use Nant: 1. Create a new build configuration called Nant(or whatever). Turn off building for all projects in this solution. 2. Switch to this Configuration. Then you can use F7 to build. And when you want to debug none of you projects will build since your configuration has them turned off. I could have had some tool do a transform on my project file into a build file. I believe there is a xsl out there to do this. This all has worked quite nicely for me. HTH -bc -- Original Message -- From: Tomas Restrepo [EMAIL PROTECTED] Date: Thu, 24 Jul 2003 11:31:33 -0500 Matthew, I'm also getting close to wanting to use NAnt completely within the build process. We do this for our project. We actually went a little bit further,and we actually have a single VS.NET solution and project that *never* get built, it's just for intellisense and the vs.net VSS integration ;) Every developer (the main dev team has about 8 people) builds directly with nant everytime (one of my coworkers came up with the idea to add a custom tool to vs.net that fires nant for the project and puts the nant output in the vs.net output window. nifty!). No problems with this setup, really. The project is not too bit, though, consisting of about 20 dlls or so, and 200.000+ lines of code, with a fairly complex build and install process (for gac and COM+ registration). -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Solution/Project Parser
It saves them all. One other good side effect of having output go to the output window is context sensitivity for the errors/warnings on output of csc. You can click on the output line and get VS.NET takes you to the source line. -bc -- Original Message -- From: Matthew Mastracci [EMAIL PROTECTED] Date: Thu, 24 Jul 2003 11:08:16 -0600 Does VS.NET save all of your files before doing a build, or do you have to manually save them? Bill Conroy wrote: My whole team does this all too. Here is the writeup I gave out a while back to the OT list on how to do this: Here are the steps I used to integrate[note I do not address keeping a csproj in sync with the build file, but I could] Do this once: 1. Add an external tool Title: Nant (Current Project) Command: nant -- assuming nant is in your path. Arguments: [I have nothing here, I use the default target in VS.NET] Init Dir: $(ProjectDir) I check Use Output Dir. This gives you output lines which are context sensitive for the file, line of the error/warning. 2. Add an external tool Title: Nant (Solution) Command: nant -- assuming nant is in your path. Arguments: [I have nothing here, I use the default target in VS.NET] Init Dir: $(SolutionDir) Check Output Dir. 3. I have hooked up F7 to Nant (Current Project), and Shift-F7 to Nant (Solution) through the Keyboard settings in Tools|Options. For each project you want to use Nant: 1. Create a new build configuration called Nant(or whatever). Turn off building for all projects in this solution. 2. Switch to this Configuration. Then you can use F7 to build. And when you want to debug none of you projects will build since your configuration has them turned off. I could have had some tool do a transform on my project file into a build file. I believe there is a xsl out there to do this. This all has worked quite nicely for me. HTH -bc -- Original Message -- From: Tomas Restrepo [EMAIL PROTECTED] Date: Thu, 24 Jul 2003 11:31:33 -0500 Matthew, I'm also getting close to wanting to use NAnt completely within the build process. We do this for our project. We actually went a little bit further,and we actually have a single VS.NET solution and project that *never* get built, it's just for intellisense and the vs.net VSS integration ;) Every developer (the main dev team has about 8 people) builds directly with nant everytime (one of my coworkers came up with the idea to add a custom tool to vs.net that fires nant for the project and puts the nant output in the vs.net output window. nifty!). No problems with this setup, really. The project is not too bit, though, consisting of about 20 dlls or so, and 200.000+ lines of code, with a fairly complex build and install process (for gac and COM+ registration). -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Solution/Project Parser
It's probably clear, but did forget to mention that to use this, you add this project to your solution and then configure your solution to turn off building for all projects except this one. The benefit from my perspective (a minor one) over the External Tool approach that some people use is that the existing Build / Rebuild functions continue to work for the solution and that build errors show up in the normal build errors task list instead of only in the Output window. -Original Message- From: Erv Walter [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 11:56 AM To: Tomas Restrepo; [EMAIL PROTECTED] Subject: RE: [nant-dev] Solution/Project Parser In the event that this is useful to others, I have attached the project we use to make VS.NET 2003 integrate with NAnt. It's a VS.Net 2003 C++ Makefile project. The way it works is that you can configure a makefile project to call whatever command you want to do the actual build. Interestingly, you will still get good VS.NET integration for any build errors. This is because NAnt uses csc.exe to do the build and VS.NET apparently understands how to parse the csc.exe error output. In order to get debugging to work (for a windows exe or console app), you will need to hand tweak 2 settings in the NantBuilder project properties. On the debugging tab, you need to set these: Command: $(SolutionDir)build\YourOutput.exe Working Directory: $(SolutionDir)\build\ For some stupid reason, these will be stored for you in the .suo file (which is why you have to do them yourself). Obviously, replace YourOutput.exe with whatever the name of your debugable executable is. For all of the above, you may need to make some adjustments based on how you have NAnt configured to build. The above depends on: - Nant.exe being in Tools\NAnt subdirectory of your solution (a convention that we use internally) - default.build being in your solution directory - build, rebuild, and clean targets in your default.build directory - all of your build output going into a build\ subdirectory of your solution If you have a different NAnt setup, you'll need to adjust the project accordingly. You also might be able to set something up similar in VS.NET 2002, but I have never tried. Maybe I'll see if I can figure out how a Wiki works and then add this information there. Enjoy, Erv -Original Message- From: Tomas Restrepo [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 11:32 AM To: [EMAIL PROTECTED] Subject: Re: [nant-dev] Solution/Project Parser Matthew, I'm also getting close to wanting to use NAnt completely within the build process. We do this for our project. We actually went a little bit further,and we actually have a single VS.NET solution and project that *never* get built, it's just for intellisense and the vs.net VSS integration ;) Every developer (the main dev team has about 8 people) builds directly with nant everytime (one of my coworkers came up with the idea to add a custom tool to vs.net that fires nant for the project and puts the nant output in the vs.net output window. nifty!). No problems with this setup, really. The project is not too bit, though, consisting of about 20 dlls or so, and 200.000+ lines of code, with a fairly complex build and install process (for gac and COM+ registration). -- Tomas Restrepo [EMAIL PROTECTED] --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01 /01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Solution/Project Parser
That makes things much more clear for me, and it sounds like a great idea. From: Yves Reynhout [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2003 4:35 PMTo: [EMAIL PROTECTED]Subject: Re: [nant-dev] Solution/Project Parser 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 filesitself. Secondly, as a consequence, the parsing code wouldn't be mingled with what the solutiontask actually does. The object model could also provide for a task that e.g. extracts the files included in a project andupdates 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 buildinga 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.
