It seems to me there are two problems:
1. We need to add multi db support to the build scripts 2. The existing nant scripts are overly complex and hard to extend and or maintain I'm sure there are good arguments for mvoign to MsBuild (I haven't used it in a while so I'm not in a position to comment much) but I'd be surprised is MSBuild is really the solution to 1. In isolation. There is a good deal of value in keeping the Nant scripts: a) They work and are 'tested' in production b) They work in mono c) People may be using them as part of other build processes and/or testing environments and might have wrapped other tools around the build scripts. Converting to MSBuild presents significant pain along all three directions. I suspect there is a lot that could be done with Nant just by cleaning up the existing scripts. From: nhibernate-development@googlegroups.com [mailto:nhibernate-developm...@googlegroups.com] On Behalf Of Davy Brion Sent: Monday, February 16, 2009 1:48 PM To: nhibernate-development@googlegroups.com Subject: [nhibernate-development] Re: proposal: move from nant build scripts to msbuild scripts it's definitely not a problem that can't be overcome... there should basically be a setting which allows us to provide a path to a hibernate.cfg.xml file so it can be copied to the test output folder before the tests are run. that way, we can just provide a path to a db-specific hibernate.cfg.xml file for each build configuration on the new buildserver (eg, for MsSQL, Mysql, ...) it turns out that there is such a setting defined in one of the .build scripts (config.FilePath) but when i try to pass it to nant it complains that it can't overwrite the read-only property. i'm sure it's a minor fix, but while i was going over the build scripts i couldn't help but notice that they seem to be way to complex for what is actually required. The fact that most people respond with a "i don't know, i generally stay away from our build scripts" whenever i ask a question about them, isn't really a good sign either I'm pretty sure i can put an MSBuild script in place which will be simpler to maintain and extend. Is nant really still that much better than MSBuild? I've been using MSBuild for a lot of projects at work and we can do pretty much everything we need to do with it. Then again, my experience with Nant is extremely limited, other than that when i see them i generally feel they are too complex for what a build script should be. and i don't really see a reason why a mixed approach between nant and MSBuild would be better than going with a single msbuild script either. i'll try to finish the script as soon as possible, and i'll post it here before i commit it so we can further review this. On Mon, Feb 16, 2009 at 10:31 PM, <jonathan.pal...@contactnetworks.com> wrote: Can you elaborate on what the issues are with Nant and multiple db configurations? Converting to MsBuild is a) a bunch of work and b) going to make Mono devs less happy. Plus I think of Nant as being a bit more powerful than MsBuild. I would have thought it makes more sense to make the db configuration problem work in nant that to rewrite. Jon From: nhibernate-development@googlegroups.com [mailto:nhibernate-developm...@googlegroups.com] On Behalf Of Ayende Rahien Sent: Monday, February 16, 2009 1:13 PM To: nhibernate-development@googlegroups.com Subject: [nhibernate-development] Re: proposal: move from nant build scripts to msbuild scripts They are not unmaintainable, they are just complex. They are also the foundation for Castle, Rhino Tools, and I just installed them for a new project :-) On Mon, Feb 16, 2009 at 10:25 PM, Davy Brion <ral...@davybrion.com> wrote: the nant scripts could remain available though... but right now, i consider those scripts to be pretty much unmaintainable and a horrible mess On Mon, Feb 16, 2009 at 9:23 PM, Dario Quintana <conta...@darioquintana.com.ar> wrote: One reason to get NAnt running is for who use Mono. On Mon, Feb 16, 2009 at 6:21 PM, Davy Brion <ral...@davybrion.com> wrote: any idea on how the msbuild story on mono is these days? ie... will it work 'out-of-the-box'? On Mon, Feb 16, 2009 at 9:20 PM, Ayende Rahien <aye...@ayende.com> wrote: +1 And I have used MSBuild for a long time in Rhino Tools I used the same generate assemblyinfo approach, you can still find it in the SVN archives. On Mon, Feb 16, 2009 at 9:57 PM, Davy Brion <ral...@davybrion.com> wrote: Hi guys, i'm trying to get everything up and running on the buildserver, and nant is causing some problems with regards to easily being able to run tests for various database configurations. Seeing as how the nant build scripts are way too complex (at least for my taste), i propose we move to a simpler msbuild script. I have some experience with msbuild, and while it's not perfect i do think it's simpler than nant. Would there be any objections from any of you with regards to moving to msbuild? There would be one breaking-change though... currently, none of our projects have an AssemblyInfo.cs file because nant creates it (i'm told to make sure that each AssemblyInfo.cs file contains the same versioning information). I've never used that approach with msbuild, but there are msbuild tasks available to keep the versioning information in synch across projects. So if we do go ahead with this, we would have to add an AssemblyInfo.cs file to each project again. Other than that, i think we can create a pretty simple script to build the project, run the tests (for whatever database configuration you'd like) and once that's working we can add automated binary and source packaging to the mix as well. So, any objections? Or other suggestions? brs, Davy -- Dario Quintana http://darioquintana.com.ar <http://darioquintana.com.ar/>
