Jeff of the MSBuild team asks what works for you when it comes to debugging a build. There probably are no hard-n-fast rules.
You really need your build system to output enough information to track things down and this requires the exact location of the error together with some contextual information at the very least. When we introduced <import> in Ant we soon learned that you really need the full stack of nested build files listed to understand what went wrong. It's not enough to say the error occurred in line 37 of build file foo/bar/baz.xml, you also need to know which build file imported that file at which line - recursively. The same applies to using the <ant> family of tasks.
It's probably easiest to locate build process failures if you have some kind of continuous integration system in place, it may help to identify the change causing problem - but then again the problem may be a server that's unexpectedly unreachable or just the time of the day.
Are there any more hints? You can tell Jeff since you don't have to register to post comments at his blog ;-)
In the comments Steve mentions that IntelliJ IDEA now supports refactoring of build files, scary.
path: /en/dotNet/msbuild | #