Nant-scripts as developer therapy
It took me quite a while to get into writing Nant-scripts for my projects. One of the main reasons for me to denounce the concept of writing buildfiles at all was that I was all too happy to be rid of those terrible makefiles I had to put up with before we had Visual Studio. Why think about what files to include, what parameters (in what order) to use during compilation and where to copy those files to get something to work when you can just press F7 (yeah I still have VC++6 keybinds) and wait for your harddisk to stop rattling? Well, as it turns out, it's actually quite a good sanity check on your build environment, plus it helps you think about installer-related problems that will pop up eventually anyway.
The way to go about this is to write a Nant script that will set up your project on a machine that hasn't previously been used to work on the project. It doesn't have to install Visual Studio, the SDK or any other required tools. We use Subversion for sourcecontrol and the general way to pull out a project is to get out the trunk of the project non-recursively (the -N parameter does this when using the svn.exe commandline tool). What you get is a readme.txt which tells you which versions of the buildtools you need, a setup.include file which contains all configurable properties and finally a setup.build, the actual buildfile. All I have to do now is type nant and sit back, while the entire project is set up and ready to run or work on right on my machine.
What happened when I started writing a script like that is that I noticed how some of the quick decisions that were made during the startup of the project were not exactly the right way to do things. For instance, the log4net install was in a subdirectory of the main project-directory. Doesn't make sense ofcourse because other projects may want to use this library as well, so I moved it around.
The database runs on the same machine for development as IIS, so the local ASPNET-user was added as a login to SqlServer and that was that. Try getting that to work without having rights to creating domain users in a scenario where IIS and SqlServer run on seperate machines. I had to jump through several hoops changing values in either machine.config and web.config, encrypting values in the registry and creating mirror accounts on both machines. This would pop up eventually anyway, but running into it before the customer is waiting for everything to go online within fifteen minutes ensures you can solve this elegantly (as far as that's possible anyway, but that's another story).
As for getting ahead on troubles you'll run into when creating an installer: some of the views were renamed in SqlServer during development. It turns out that if you do this, SqlServer messes up the dependencies so the script that is generated probably won't run on an empty database. So you remove those views and recreate them instead. It's better to tackle these kind of things daily than run into them all at once when your projects is supposed to be nearing completion.
And best of all, working with these scripts gives me the same kind of secure feeling about the state of the project as using unit-tests while refactoring. In fact, every monday morning the first thing I do is remove my project-directory (I used to rename it to .old first, just to be sure), check out the buildfile and recreate the build-environment. This way I know for sure there's nothing vital to the project on my machine that's not in the repository.