4 Comments

  • Keep us posted with your progress on this Royo - I'd love to hear how you tackle it and what solution you end up with. I've got a ~70 project solution which I need to build so, I have a similar problem to yours.

  • Just to give my $0.02, I just started playing with a build/automated testing for here at work (they'll never adopt such procedure of course)...and felt way strong against using nAnt for the reasons you mentioned. But I gave it a try and it was a real breeze. Within 1/2 a day I have the project building automatically (source/debug/stage) with nUnit test cases running against the builds. Of course this was for a single project :)



    However, something I didn't try doing was using nAntContrib's <slighshot> task to convert a .sln to a nant build file. If <slingshot> works as straightforward as all the other nant tasks, I'd highly recommend it.

  • Are you using the Visual Studio database project to maintain your database schema scripts? If not, maybe thats something to look into. Otherwise, make a habit of always saving database changes as change scripts. Keep them centrally located, and write a little utility (or .cmd file using "for /F ..." ) that iterates over all the change scripts and executes them with osql (or the equivalent for your db if not MSSQL).



    I've often thought about, but never decided - for each "version" (schema change) of the database, should I just maintain the change scripts, or should I also reverse engineer the create scripts for the entire DB? Hmmm.... The answer is somewhere in between I think.

  • Sure would be handy if there were an indicator, down here in this comment area somewhere, as to whether or not HTML is supported in comments ;).

Comments have been disabled for this content.