NAnt versus MSBuild

At work we are currently converting from NAnt to MSBuild scripts as we convert from CruiseControl.NET to TeamCity. Why are we changing from NAnt to MSBuild as we change CI servers? Nobody really knows for sure besides the guy that is running the project basically says, "I've mandated it." That's the only reason. Seems like a silly reason to be to go through all the trouble to rewrite all the scripts.

After working with NAnt and MSBuild I have come to one conclusion: I don't like XML based scripting languages. That's right, you heard it here. They are both a pain. Way too verbose and too much of a PITA. My personal belief is that we should just wrap all the functionality with a perl script and be done with it. :-) Just think about it: Simple if/then/else statements and simple loops without all the XML filler junque and all the dynamic data structures you want without a bunch more XML filler stuff. It's beautiful! Back in my day, you darn whipper snappers, we had .CSV files and liked 'em! And like Ant/NAnt, perl works under both Unix and Win32 (I've been using Win32 for a gazillion years but now that I run a 64-bit OS should I start saying Win32/64? That's a discussion for another time! Now back to my MSBuild and NAnt rant!) so you have multiple platform functionality.

MSBuild is taking me longer to wrap my head around. I don't like that I can create a property inside of a target, but that property is not available until the target where it was created as finished. Makes it a pain to attempt to modularize common calls for database work. And why doesn't MSBuild have a foreach construct? Sure, you can use the metabase accessing `%` to invoke multiple calls but how non-intuitive is that? Argh! I shouldn't have to write a helper function to make multiple calls with the % operator.

Yeah. I stand by my convictions on this one. Junque both of 'em and write a perl wrapper and be happy.