Build vs. Compile

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/build_vs_compile.htm]

In the Microsoft development world, I hear a lot of "non-process-oriented" developers intermix the terms "build" and "compile". I can understand why; I used to be that way myself. For example, if I look at even the new VS2008, the "Build" menu will by default just compile your solution. Sure, you can add pre-build and post-build command line calls, but the point is that out-of-the-box, if you just use VS2008 on a small project, it's easy to think that "building" means "to just compile your code".

 

Building is so much more, hence Microsoft shipped MSBuild back in 2005. A full build process may include many steps, of which compilation is just one:

1. Check out source code

2. Run active code-generation

3. Ensure external data stores can be upgraded (i.e. nothing broke the database schema)

4. Compile

5. Run unit tests (ideally with code coverage)

6. Run other tests (performance, stress, functional, etc...)

7. Run static code analysis

8. Create MSI install packages

9. Publish those packages somewhere

10. Publish results to the team (i.e. email/rss feed the build's status)

A lot of developers have CruiseControl running on a dedicated build server, kicking off an MSBuild (or maybe an NAnt) script to run all this.

 

So, the moral is that "Build" != "Compile". Rather, Compile is just a subset of Build.