Re: [nant-dev] Continuing work on msbuild-solution
Andy, its quite a time since this discussion. I just want to ask you, how you feel msbuild-solution, if you're still using it etc. Our feelings to both NAnt and MSBuild was very simmilar, and I'd like to know any news about task and nant/msbuild in general. I, personally, am still using it, for almost half a year, without serious problems. In this time, we are moving completely towards 2.0, and this stuff becomes more important to us. If there is enough interest, I'm willing to make this task self-contained, or add it to nant-contrib, or even NAnt core, whatever. If not... that is fine too :-) But I'm still not sure, this is the way, NAnt would go. That saddens me... Martin Aliger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Davey Sent: Tuesday, February 07, 2006 5:32 AM To: nant-developers@lists.sourceforge.net Subject: RE: [nant-dev] Continuing work on msbuild-solution Mike wrote, It would be a mistake to build any logic to parse VS2005 solution files into NAnt because that file format is almost certainly going away in the next version. (The only reason it's not an MSBuild file now is because MS basically didn't have time to finish it for VS2005). I'm not sure that I entirely agree with that. Using MSBuild to perform the actual build is a great idea. Nant is so powerful in so many other areas it doesn't loose anything by pushing the compiling work over to MSBuild (especially when you consider that MSBuild may be used to compile for/target Mono [http://blogs.msdn.com/jomo_fisher/archive/2005/08/31/458658.aspx]). But at the same time there are a couple things you can do with solution that I haven't found easy to replicate with an msbuild task. The show stopper for me at the moment is getting MSBuild to direct all build outputs to a particular folder (I'm not saying it can't be done...I just haven't found a solution that is as nice as the 'outputdir' property of the solution task). Considering the progress that Martin has made with the msbuild-solution, I don't think it would take much effort to add support for solution's 'Solution' property. VS 2005's sln format is not that much different to VS 2003. I don't know about any proposed changes to the 2005 sln format (except to say I wouldn't be surprised if they dothey have always in the past), but that bridge can be crossed when we come to it. I also think that having a msbuild-solution will make it clearer to Nant users of a relatively smooth migration path for updating Nant scripts to work with VS 2005. However, it's also not important: msbuild.exe knows how to parse the solution format. It doesn't matter if you supply a project file or solution file, it will just build. Agreed. I just need to work out a way to mimic 'outputdir' functionality that I used with solution. Andy --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486; dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Continuing work on msbuild-solution
does very good job on reference resolving. Just not good enough in some cases. There are even MS blogs about it, if you like to find them. It do _not_ follow project build order when building more projects at once. It could read order from .sln file, but thats all. It never try to find out correct build order for list of projects like NAnt do. And this one was showstopper for me. Huh. Perhaps you could forward a link to some of those blogs. As I said, I've found MSBuild to be perfectly adequate so far, including building projects in the proper order. If I'm missing something I need to know about, I'd like to know about it before it blows up in my face. :-) Or, for example, what about mixing VS2003 and VS2005 projects? Ah well, I don't do that. I use MSBuild for the 2005 projects, and the solution / task for the 2003 ones. Again, it's worked just fine so far, though I will freely admit that our 2003 projects are *very* simple compared to the 2005 ones. Crosscompiling would be other example (even I'm not sure it could be done with msbuild. Maybe net-2.0 - mono-2.0 crosscompile?). I saw some blogs about msbuild be able to target net-1.1. Not sure about those though. Haven't tried that, haven't had a need to, since we're phasing out what little 2003 stuff we had, so I can't contribute anything to that conversation. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Continuing work on msbuild-solution
Has anymore work been completed on the msbuild-solution task? However, developers who are in a similar position as myself, who have relatively easy to compile solutions and are migrating their applications over to VS 2005, are forced to make a decision. Do we stick/use NAnt, or do we go with what Microsoft is pushing (or the third option, going with an expensive visual build system). FWIW, I've had great success just using the exec / task for running MSBuild. It works just fine, and I can pass in any of the parameters I want. We started using it just about 5 minutes after we started building our .NET 2.0 applications, i.e. long enough to modify the build files to accomodate it. /bs --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Continuing work on msbuild-solution
FWIW, I've had great success just using the exec / task for running MSBuild. It works just fine, and I can pass in any of the parameters I want. We started using it just about 5 minutes after we started building our .NET 2.0 applications, i.e. long enough to modify the build files to accomodate it. Sure, exec works for almost everything. But I guess, you'll soon find, you miss some features from solution which msbuild do not solve. Like resolving project dependences. Or something NAnt specific. 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Continuing work on msbuild-solution
FWIW, I've had great success just using the exec / task for running MSBuild. It works just fine, and I can pass in any of the parameters I want. We started using it just about 5 minutes after we started building our .NET 2.0 applications, i.e. long enough to modify the build files to accomodate it. Sure, exec works for almost everything. But I guess, you'll soon find, you miss some features from solution which msbuild do not solve. Like resolving project dependences. I haven't had any problem resolving project dependencies. MSBuild seems to be smart enough to navigate the hintpaths defined in the various project files and deals with those just fine. Even the COM Interop stuff is working just peachy keen. Or something NAnt specific. Like what? --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Continuing work on msbuild-solution
I haven't had any problem resolving project dependencies. MSBuild seems to be smart enough to navigate the hintpaths defined in the various project files and deals with those just fine. Even the COM Interop stuff is working just peachy keen. There are issues, believe me. Maybe its not problem for you, but it is for many of us. You're not obliged to use any specific task if you dont want to - just stick to exec if you like :-) Hintpathes are ok in some cases, but in they are not in many others. But to be right: msbuild is much smarter than just navigate hintpathes. In fact, it does very good job on reference resolving. Just not good enough in some cases. There are even MS blogs about it, if you like to find them. It do _not_ follow project build order when building more projects at once. It could read order from .sln file, but thats all. It never try to find out correct build order for list of projects like NAnt do. And this one was showstopper for me. Or something NAnt specific. Like what? Like assemblyfolders, projectreferences. Or resolving assembly reference from its output filename, which is added value even for vs2003 solutions. Or, for example, what about mixing VS2003 and VS2005 projects? Crosscompiling would be other example (even I'm not sure it could be done with msbuild. Maybe net-2.0 - mono-2.0 crosscompile?). I saw some blogs about msbuild be able to target net-1.1. Not sure about those though. 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Continuing work on msbuild-solution
Andy Davey wrote: Has anymore work been completed on the msbuild-solution task? Nothing official that I know of, beyond what you've seen in the archives. I tend to agree that, unless you make the effort to dig back through this list's archives, NAnt looks like it's basically dead in the water :( But word is that a new release is due any time now so hopefully that's a temporary problem. But I would like to investigate adding support for the 'solution' property as well as a few other things (like would it be possible to add a OutputDir property to the msbuild task). I don't want to start making changes however, until it's clear that msbuild-solution is the way that NAnt is going to go. It would be a mistake to build any logic to parse VS2005 solution files into NAnt because that file format is almost certainly going away in the next version. (The only reason it's not an MSBuild file now is because MS basically didn't have time to finish it for VS2005). However, it's also not important: msbuild.exe knows how to parse the solution format. It doesn't matter if you supply a project file or solution file, it will just build. -- -- Mike Still using IE? Get Firefox! http://www.spreadfirefox.com/?q=affiliatesid=6492t=1 --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Continuing work on msbuild-solution
Mike wrote, It would be a mistake to build any logic to parse VS2005 solution files into NAnt because that file format is almost certainly going away in the next version. (The only reason it's not an MSBuild file now is because MS basically didn't have time to finish it for VS2005). I'm not sure that I entirely agree with that. Using MSBuild to perform the actual build is a great idea. Nant is so powerful in so many other areas it doesn't loose anything by pushing the compiling work over to MSBuild (especially when you consider that MSBuild may be used to compile for/target Mono [http://blogs.msdn.com/jomo_fisher/archive/2005/08/31/458658.aspx]). But at the same time there are a couple things you can do with solution that I haven't found easy to replicate with an msbuild task. The show stopper for me at the moment is getting MSBuild to direct all build outputs to a particular folder (I'm not saying it can't be done...I just haven't found a solution that is as nice as the 'outputdir' property of the solution task). Considering the progress that Martin has made with the msbuild-solution, I don't think it would take much effort to add support for solution's 'Solution' property. VS 2005's sln format is not that much different to VS 2003. I don't know about any proposed changes to the 2005 sln format (except to say I wouldn't be surprised if they dothey have always in the past), but that bridge can be crossed when we come to it. I also think that having a msbuild-solution will make it clearer to Nant users of a relatively smooth migration path for updating Nant scripts to work with VS 2005. However, it's also not important: msbuild.exe knows how to parse the solution format. It doesn't matter if you supply a project file or solution file, it will just build. Agreed. I just need to work out a way to mimic 'outputdir' functionality that I used with solution. Andy --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Continuing work on msbuild-solution
Hello, Has anymore work been completed on the msbuild-solution task? No, nothing serious since early january. I'm testing overall stability and performance on our enterprise build. But most of our projects are still on net-1.1. Anyway, it looks very well. Looking through the archives there was mention of moving it into NAnt-Contrib, but the last time I looked that hasn't happened. It do not happens yet. Mainly becouse of needed patch to main solution task, which wasn't still submitted (or I do not know about it). But I would like to investigate adding support for the 'solution' property as well as a few other things (like would it be possible to add a OutputDir property to the msbuild task). I don't want to start making changes however, until it's clear that msbuild-solution is the way that NAnt is going to go. Exactly the reason why I do not continue the work. If I know, its the way where NAnt would like to go, I'd gladly improve it somewhat. Gert, Ian? How you see it? I believe that the solution task was an important win for the NAnt project. People (like me) who don't have a complicated solution/project structure and who use VS for their day to day compiles didn't want the hassle of updating their NAnt scripts every time they added/removed a file from their project. Without the solution task, I don't know if I would have been able to justify using NAnt as a build process. (Which is funnymy NAnt scripts are around the 3000 line mark, of which maybe 100 lines deals with the actual compile). Very same here :-) Really funny thing - 3000 line script and only few lines about building itself. In contrast, msbuild files (scripts) are all about build. In fact, I like it much (better than solution), but it (main) purpose it elsewhere. And I see NAnt/MSBuild coexistence useful. Ok, it is competetive in some respects, but It could be also nice complement. It wasn't until I started to browse this list's archive that I could see that NAnt was alive and that work was being done to get NAnt working on VS 2005. The sooner this work is made more visible (ie getting it into the nightly build of either NAnt or the Contrib), is blogged about, has a code project article etc etc the better off NAnt will be. I feel it simmilar. I know, there is real work and NAnt is just pet project like many open-sources. Even that officical releases are so rare add to this feel. I wish next release will be soon and with stable msbuild support :-) PS Martin I'm very grateful for the work that you've done towards the msbuild-solution task. Thanks much! :-) You are (of couse!) free to experiment with that solution handling. It shoudn't be difficult. And btw: I'm not afraid of .sln parsing. We could handle new format at time MS publishes it. Regards, 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
