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 > > > > >
