The case for MSBuild

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

<XML />

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”.

Highly reusable

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.


Sayed Hashimi said...

Thanks for the post, I agree with a lot of your points here. Also another thing that people don't typically factor into their thinking is tooling support. Since MSBuild is XML it is easy for tools like Visual Studio to easily integrate with it.

Matt Honeycutt said...

I consider myself to be moderate-to-advanced in my MSBuild knowledge. I've written build and deploy scripts for several apps with it. I've authored several custom tasks. To this day, I use it for deploying updates for one of the commercial apps I support. I don't think it's a bad tool, but I think it's uses are pretty limited simply because there are now better tools for the job. I think it's a good fit for simple declarative tasks like (surprise) building a project. For things that require logic though, I think MSBuild is actually a pretty poor choice compared to the other things that are out there. Can it do pretty much anything you'd ever want? Sure, but you can make that argument with COBOL, C, C++, etc.

For me, the big disadvantage of MSBuild is how verbose and complex it is for even simple tasks. Most of that is due to the declarative and verbose nature of XML. There's a lot to be said for terseness. What might take 4 or 5 lines of XML with MSBuild can be expressed with no loss in readability in 1 line of Powershell. In fact, the Powershell command is likely to be more readable just because it has less ceremony cluttering things up. Don't forget common, simple things like for loops don't map well to MSBuild, but they're trivial to express in an imperative language.

So, I think that's one reason you don't see much love for MSBuild: it's not that people hate it, or that it's not cool, it's just that MSBuild wasn't never really built to handle some of the complicated things that people are now doing with their build and deploy processes. Other tools have cropped up that solve a lot of those problems more elegantly than MSBuild can.

Buddy James said...

I've recently started to use MSBuild (manually) on a project and I'm impressed. I've accomplished some really great things and I haven't had to touch any custom configuration. I used visual studio to set up a custom build configuration and also to setup an msdeploy profile for that configuration. The result is one call to msbuild on my solution with the right parameters and my entire solution is built, a web deploy package is created and deployed to my environment that I setup in visual studio. Anyway, great blog.

Designed by Posicionamiento Web | Bloggerized by GosuBlogger