When to use a build tool?

Question

A beginner question, bear with me: I\'m just wondering under what circumstances one should use a build tool like nant or msbuild? I\'m working on a medium sized application (.ne

Answer 1

When you start doing releases or when your build exceeds certain number of manual steps (you'll notice when it starts getting annoying.) I've written an old blog entry on this topic which you might find interesting.

Answer 2

It sounds like you are using an IDE to do your build. It essentially is a build tool; you are already using one. You should switch tools when the one you are using becomes more of a problem than a solution.

Answer 3

Are you developing with Visual Studio? In that case, you are already using msbuild, since that is the underlying build engine of Visual Studio. Actually, a Visual Studio project file is nothing more than a msbuild script.

Apart from that, you can use the build engine on a dedicated build system, so that your binaries can be built unattended and without having Visual Studio installed. You can also use that for unit-testing.

Answer 4

Agreeing with and expanding on zacherates' answer ... Yes, you should always have some repeatable build process. While technically Visual Studio projects are MSBuild files, it's better to have the "official" build process be separate of the development environment.

In my mind, this is true no matter how big (or small) the team is. I use NAnt and CruiseControl.NET at home, where all I tend to work on are scratch projects and experiments. At work, we use a similar setup, but a bit more structured in how the NAnt scripts are put together.

It's definitely worth your time to look into it. It's not a cure-all, but it is a best practice for knowing exactly which build was released when, and what's in the wild. Being able to identify your compiled code is half the troubleshooting battle! :)

Answer 5

If you want to automate anything it's good to use nant/msbuild. For example: 1. check in 2. build 3. test and code coverage

Answer 6

I think any non-trivial application needs a 'build tool'. We use the term Continuous Integration where I work. There are very exceptional cases (e.g.: I'm building a sample app to learn how feature X works), but aside from those, you'll never regret having a solid build process.

I guess that if the development team was made up of one person... I'd still set up a build system including a repository, a building tool, and multiple suites of tests. Yes, maintaining the build system costs time and money, but it will pay off (I've been working for 40 months now on a project that started with 6 developers, and includes about 30 developers now; it did pay off for us a number of times) in terms of quality control, and the sooner quality issues are detected, the cheape they are to fix.