MSBuild Blah's

I did get to spend more time with MSBuild and I've got to say as a build tool for Microsoft its spiffy.  As a scripting tool/language for either automating packaging, or deployment, it comes in as just 'ok'.  There are two constraints with MSBuild that require a slightly different way of thinking when approaching how to automate different parts of the package and deployment process: lack of foreach and item collections (ItemGroup) conditions are only evaluated once when determining whether a Task executes for that ItemGroup (for performance). 

Neither is insurmountable.  The first is slightly problematic for me - I just seem to be wired to think in 'foreach'. The second part of the item collections only being evaluated once means that if I've got an ItemGroup with different metadata values, I can't just throw the ItemGroup at a Task and let the Conditional on the Task determine what executes - only the first item(s) to match the condition will execute (or not) - the rest won't be re-evaluated, even if their values are different.  This means I've got to cruft up a dynamic ItemGroup to throw at the Task. Nant does foreach very well - its a first class language construct.

Oh, I'd like to throw a third in there as well - easily iterating child folders of a parent.  There seem to be workarounds: parsing dir command output, custom task, or third party community tasks.  None of which are intuitive enough for me.  Nant has a 'Folder' collection that works well in this scenario.

The other thing that just stands out is that I have never, as in EVER, lost any time figuring out how to accomplish something with Nant.  Even back when getting started I don't remember being stymied in getting something done.  Just set 'em up and knock them out.  With MSBuild, its par for the course.  Make some progress, get stymied for an hour or three, make some progress, roll back that progress, rinse and repeat. 

Clunky - but doable.  I'm getting it, I just don't like it.

What still amazes me is that people, myself included for which I am still slightly embarrassed, keep trying to justify using one tool or the other.  Because we are primarily a Microsoft shop, Microsoft tools tend to get a priority they may not rightly deserve.  In any case, with time == money, if I can accomplish a task in half the time (or less in some cases) why keep pushing for the 'breakthrough' with a different tool?  It just doesn't make sense.   I think it comes back to pride/ego: I can do this. 

Make sure you've got the right reasons for tool selection.  Vendor preference is not necessarily the right one.  Not having to distribute the runtime is such a minor inconvenience as to not be mentioned - especially something as file copy centric as Nant.  Integration with TFS?  TFS can kick off just about any process - Nant is just fine.  Nant can call MSBuild just fine (and vice versa).  There are really two considerations: development and maintenance.  How fast can you get something done and how easy is it to maintain when you need to fix/enhance?

One co-worker's mantra is "build with MSBuild, but automate with Nant" - he should know.  I asked him to walk this path (2 years ago?) and had him automate our package and deployment process with MSBuild - for the wrong reason. He did it, but it took him much longer than expected for many of the same reasons I've mentioned here - and when he did it there wasn't a whole lot of blog content to fall back on either. 

Don't get me wrong - MSBuild will work. I really do like the Item metadata feature of MSBuild and I am *that* much closer to the breakthrough that I'm probably not going to stop now - its a matter of pride, stupid pride.