james mckay dot net

I mentioned this in passing in a recent blog entry, and I thought I’d expand on it a bit.

I do not like NAnt.

I do not like MSBuild either.

I’ve used both of them, and quite frankly, I don’t see the point of either of them. To be sure, MSBuild allows you to build Visual Studio solutions from the command line, but that’s MSBuild the program. MSBuild the language, on the other hand, is a completely, utterly pointless reinvention of NAnt, which itself is probably the most completely, utterly pointless domain specific language in widespread use that I’ve ever come across.

Neither language does anything that you can’t do in Python. In fact, most of the time, Python does it better, with a cleaner syntax because it isn’t XML-based. XML is fine for some things, but the foundation for a scripting language is not one of them. When you’re using XML as the basis for your scripting language, you’re getting dangerously into “all you have is a hammer, so everything looks like a nail” territory.

Besides, neither of them are used anywhere for anything other than writing build scripts. If you use Python, at least you can leverage your knowledge for other domains, such as web development, game development, OS scripting, and much, much more.

I say Python here purely because I happen to know it. There are other decent, popular, multi-purpose languages that you can use to write build scripts. There’s no reason why you can’t use Ruby, or PowerShell, or even good old fashioned batch files, for instance. But having to learn and use a fiddly, awkward new language solely for the purpose of setting up or changing your build scripts—something that you only do relatively infrequently—simply doesn’t make sense.

Comments (1) »

Posted at 08:00 on 23 March 2010.
Tagged: build scripts, MSBuild, NAnt

I have a long-standing gripe about web.config files. They are where you are “officially” supposed to put all your application’s configuration settings, but the framework throws in a whole lot of other so-called configuration settings that are, to all intents and purposes, code. Such as HTTP modules, assembly references, which version of the C# compiler to use, and so on.

This is bad. A well-designed application configuration file will only contain settings that vary from one deployment to the next. Anything that is the same across the majority of deployments should be set in your code either by convention or by default values. Anything that doesn’t change from one deployment to the next is not configuration, but code.

But why not just stop using web.config for your app settings and connection strings altogether? There’s nothing stopping you from writing your own configuration class which pulls in all your application settings and connection strings from a JSON file in the parent directory to your application root, or in the Windows registry, if that’s what you need to do.

Build scripts are another example. What language do you use to write your build scripts? Chances are, you either use NAnt or MSBuild. But both of these are XML-based, unwieldy, tricky to learn and use, and somewhat limited. What’s to stop you using Python or Ruby instead, or even batch files, for instance? They can do everything that NAnt and MSBuild can do and more, they are much simpler to understand and edit, and you can leverage the knowledge involved elsewhere.

Just because the framework provides you with an “official” way of doing something, it doesn’t mean you have to use it. Using a different approach to the officially touted way may sound a bit radical or perhaps even iconoclastic at first, but it makes perfect sense once you think about it. After all, if the accepted wisdom passed down from Redmond is not fit for purpose, blindly sticking with it even though it gets in the way is just cargo cult programming.

Comment on this »

Posted at 08:00 on 15 March 2010.
Tagged: build scripts, configuration