When to use the build tool?

Question

Beginner’s question, carry me: I’m just wondering under what circumstances should I use a build tool like nant or msbuild? I am working on an average application size (.net 3.0), each developer does his work and builds his own machine, checking his code changes in the repository when he goes. Once we are done, I will get all the code from the repository, make a clean build on my machine, and deploy the binaries. Just out of curiosity, where does the build tool go in?

Answer 1

The short answer is always.

Each developer should build using a build script before testing the code. The people creating the release should use the build script to create the release. Your assemblers should use the build script to build and test the code that has been tested.

This allows all developers, testers, and builders to have a consistent, repeatable build. After all, the F5 Key is not a build process .

Answer 2

It looks like you are using the IDE to create your assembly. It is essentially a building tool; you are already using it. You have to switch tools when the one you use becomes more of a problem than a solution.

Answer 3

The build tool should be used when your build process becomes longer than one command. It should be used to return the standard build process to a single command. If your build process is longer than one command, then you have the possibility of errors arising from missing / duplicated / incorrect commands executed during build.

Answer 4

I think that for any non-trivial application you need a "build tool". We use the term “Continuous Integration,” where I work. There are very exceptional cases (for example: I am creating an example application to find out how function X works), but besides those, you will never regret that you have a reliable build process.

I assume that if the development team was made up of one person ... I would still install a build system, including a repository, a building tool, and several test suites. Yes, supporting the build system takes time and money, but it will pay off (I have been working on a project for 40 months that started with 6 developers, and now it includes about 30 developers, it paid off for us by the amount of time) in terms of quality control, and the faster quality issues are detected, the more they will be fixed.

Answer 5

When you start making releases or when your build exceeds a certain number of manual steps (you will notice when you start to annoy.) I wrote an old blog post on this topic that may seem interesting to you.

Answer 6

If you want to automate anything, use nant / msbuild. For example: 1. register 2. build 3. Code verification and coverage

Answer 7

Do you work with Visual Studio? In this case, you are already using msbuild, as this is the basic build mechanism of Visual Studio. In fact, a Visual Studio project project is nothing but a msbuild script.

In addition, you can use the build mechanism in a dedicated build system so that your binaries can be built unattended and without installing Visual Studio. You can also use this for unit testing.

Answer 8

By agreeing and expanding the zacherates answer ... Yes, you should always have some kind of repeatable build process. Although technically Visual Studio projects are MSBuild files, it is best to have an “official” build process separate from the development environment.

In my opinion, this is true no matter how large (or small) the team is. I use NAnt and CruiseControl.NET at home, where I usually work - these are projects and experiments from scratch. At work, we use a similar setup, but are slightly structured in how the NAnt scripts are compiled.

It is definitely worth your time to learn it. This is not a cure, but it’s best to understand which assembly was released, when and what in the wild. Being able to identify your compiled code is half the battle for troubleshooting! :)