R – Development Experience with using MSBuild/Nant vs Visual Studio 2005/2008

Yes, it's in the Debugging section of the properties page of the project.

In Visual Studio since 2008: right-click the project, choose Properties, go to the Debugging section -- there is a box for "Command Arguments". (Tip: not solution, but project).

For starters, this isn't an ambitious goal, it's a common thing with well supported tools. So you're on the right track, and good on you for so clearly identifying your priorities.

Scripting

First off, Don't, if you can help it, use bat files. The bat scripting language is, well, horrible. There are many, many language constructs that are missing from it, and it is hard to do anything complicated at all. Experts can do quite a lot of stuff with bat, but my experience with bat scripts in build systems is that they are universally unmaintainable.

You will want to write a number of OS level scripts to put all this together, but you want a solid programming language to do it in. Recommendations include:

1. Powershell
2. Python
3. Bash (i.e. cygwin)

nAnt is a fine tool for managing your build steps. The fact that the config xml gets checked in, branched, merged, diffed with all the rest is a huge advantage.

Make and Scons are also good tools.

A couple of notes about these scripts. They should have clean output and good error messages. I mean great error messages. You can't spend too much time writing build scripts that give good error messages. Seriously. Also, manage your OS error codes carefully, and make sure that each build command raises an error code if it fails. All of the CI servers will use this to red flag a failed build. If you fail on step 2, but don't raise an error code until step 10, it's very hard to debug.

Unit Tests

Yes, they should be part of your build. Nowadays there exists a unit test framework for every programming language under the sun, and they all run off the command line. So pick whichever one looks best and you're on your way.

Continuous Integration

Once you get your build process to a point where you can sit down to a command shell and get a Full Build, from Soup to Nuts (i.e. from source code to shippable), then it's time to look at what they call a continuous integration tool/server. Jenkins is a good one, so are Cruise Control and Buildbot. I've used them all, they're fine, pick one and go with it. Once you get going, they're not that hard to learn, and they manage a lot of the notification stuff you were asking for. The main thing to keep in mind is that they are all for the execution and reporting of command line arguments (more or less)

When you structure your build process, remember that it consists of four basic steps:

1. Getting code out of the repository
2. Pre-build; updating version numbers and so on
3. Compiling/building
4. Post-build; packaging; zipping up build products, making .iso images and the like
5. Publishing: moving the build products to someplace where people can find them (in your case a web server)

Config Files

If you have your config management down to one file, take a bow. This will pay you big dividends. You say that you don't want to maintain three different files. Can you identify a set of rules that would transform one base file into the three files to publish? If so, then you can write a script that does that transform for you during the packaging phase. Remember when I said "Don't use bat files?" This is the kind of thing that bat files are terrible at, and these kinds of tasks always find their way into build systems.

Conclusion

Finally, remember that the point to all of this is to:

a. Make sure there are no manual steps between submitting code and delivering a product. People are terrible at that sort of thing. They make mistakes, they don't work weekends all the time, stuff like that.

b. Give developers rapid and full, concrete feedback that what they submitted will work.

Good luck!