I was talking to a fellow developer on Facebook (I know, that’s not twitter, wtf!) and he was asking about build and deployment issues – specifically some frustrations around MSBuild. I suggested some things to help with his issues and utilize it better. That kinda got me thinking about how it seems many people don’t know how to use MSBuild in-depth (not that I’m an expert by any means). It seems to be dismissed very early and easily as a build and deployment solution. So, I’m taking the not trodden road, the dusty path, going where no man has gone before…and blogging in favor of MSBuild…in 2011!
(Note: This post isn’t actually how to use MSBuild itself. It’s me talking about why it’s worth taking the time to actually consider/learn it.)
The Case Against
Man, do people hate XML! Nothing more to really say about this – you either hate it or you don’t care. I don’t think anyone (well, human at least) loves XML. At least it’s not EDI, right? However – remember that writing your own MSBuild task can be as simple as inheriting from a base class and overriding Execute(). So if you want to do your whole build/deploy with a .NET language, you can, with a minimal amount of XML.
It’s not sexy
Okay, well, noone has said those words, I don’t think, but that’s what people’s faces say whenever you mention MSBuild. It’s not “the new hotness” by any means and it requires a learning curve. Any other new sexy build technologies have a learning curve too, but for whatever reason, developers (myself included) are much less likely to want to learn something when it’s an old product.
Rob wrote a post saying you should consider it
If I say it, it must already be wrong! I’m totally dooming myself to internet unpopularity! Zomgz! And anyone else who agrees with me even in the slightest will share my dark corner of internet shame. Next I’ll be posting about how awesome VB.NET is, how MSTest is soooo much more awesomer than nUnit, and how WebForms really got the web right! <CharlieTheUnicornsFriends>SHUUUUUUN!!!!</CharlieTheUnicornsFriends>*
*Oh god, I’m using XML even in my blog posts now!
It’s not updated for user friendliness…or I don’t think is…hell I don’t know!
There doesn’t seem to be a real….community around MSBuild. If new updates are happening to it, I’m unaware of them (and I follow several MS blogs..maybe it’s the wrong ones?). Either way, I do not believe it gets updates that would make consumption of it easier, or have more things “baked in”, and some of the other new build tools are more likely to have that user-friendliness and open-source community guiding the directions of their product.
The Case For
*Man, I’m making lots of “notes” in this one! Anyways, none of the “case for” necessarily mean it in a “competing-product-x-cant-do-this” fashion. I’m simply saying that MSTest CAN do these things, and a lot of people seem to think it can’t, or that it’s a big hassle to do these things with MSBuild, which is not the case.
You, and your grandma, already have it installed
“Laziness” isn’t a good criteria for choosing your toolset, but simplicity is. As long as you’re building on a Windows machine, you already have all the tools you need*. You just run it from the command prompt (or better yet, a batch file).
*note that the normal .NET installation does not have web-related targets by default however, which docks 5 internet points from MSBuild. What I’ve done is make a self-extracting exe, that you can call from a custom MSBuild target. You run it once on a given machine, and it’s set from there on out. You could probably do something similar for installing needed software for other builders too though.
You’re already using it
Like it or not, you’re using MSBuild! Until I started writing my own custom targets, I never really groked what was going on in a *.sln or .*proj file. This helped me learn more about how .NET solutions and projects are arranged, how things are coordinated “underneath the hood”. You can always read a book or a blog about these things, but I always find you can’t really understand something until you have to deal with it by hand. Knowing more about what you’re dealing with can a help a lot when you start having issues in your project/solution files, or want to add/edit post/pre build steps.
There’s a nice existing library of community addons
Chances are, if you’re thinking about doing some lower-level task (like, for example, reading XML out of a config, or starting/stopping windows services), there’s probably already a task out there. Granted, other frameworks have this too, and the MSBuild Community Tasks haven’t been updated in forever (remember, it’s old! Time to move on!), but the point is, there is a library out there that’s extremely useful and tackles a whole lot of common cases. The point being – there’s more than what’s just built-in that’s easy to get. A lot of people don’t seem to know this.
Yes, you can do that with it
Whatever “it” is, you can accomplish it with MSBuild. Again, not saying that other frameworks/methods don’t have this either – but MSBuild is extremely powerful. A lot of people seem to equate “XML = Useless”, and I just want people to understand that’s not the case. The fact that you can write your own C# library and have MSBuild run commands in it literally means “can do anything”.
It’s extremely easy to factor-out common targets to reuse them across multiple projects or even multiple solutions. On a previous project we had 3 websites being deployed to 5 machines, all using the exact same target, with no repetition. You can usually factor out things into more targets and chain them or composite them together as needed in higher-level build files. Yet again – not a unique feature, just saying MSBuild supports it, and it’s easy.
What Really Matters
It’s good to remember to come back and focus on what’s important – delivering value. Build and deployment is a very serious part of any project, and unfortunately most of the time it gets cast aside, only to be rushed through at the last minute. Good agile software techniques are teaching us and the industry as a whole to consider these things up front and to make them painless. The fact that we’re even discussing it at all is a great thing! Noone really recommends “deploy from Visual Studio to prod” or “copy these files, then hand-edit that config, the don’t forget to insert these rows in the database…” as a serious technique anymore. What’s even better is that there ARE options out there!
I just hope that after this people keep an open mind about MSBuild, and realize that it’s a powerful solution that can work great on .NET solutions. It’s as “correct” a solution as alternatives such as Albacore, Rake, PowerShell, etc. The only real differences are likely to be your opinion for what fits your style/team/situation better.
So what it boils down to, again, is delivering that value. Pick something that your team is interested in, that your company can easily support and maintain, and that efficiently works with your processes.