At the MSDN site, it states:
"... install Team Foundation Build on a computer that is dedicated to running builds."
OK, I got that. But my manager didn't, and I wasn't able to convince him.
This way, I aske the SO community to help me convince him of the need to use a dedicated computer to run builds.
Building is a CPU intensive process. The idea of a build server is that it sits there and builds after every checkin, to make sure nothing broke. If you put that on a computer with other resources, it's going to slow down everything else. Even if you virtualized it, it's probably going to be a problem.
The other thing is that you want a "clean" OS install so that other programs don't contaminate the computer by adding dependencies that client computers might not have.
If you only used it for nightly builds, I would think you'd be OK running a virtual machine to do it.
For one its a reproducible environment, the phrase "But it works on my machine" will no longer be heard. It takes the load off the developer machines and ensures everyone is up to date and everything has been checked in.
Joel Spolskys article might be useful to you (a little past the middle where he talks about a daily build server).
This question also has several more answers.
You can also include tests that run automatically after building, including unit tests and performance tests. The system can be configured to export a fully functional installer that can be made available on the intranet for other departments to download and use/test. This saves a lot of time and money if you have to do it every week or month.
Should you configure your build server to rebuild every time someone checks in a change, then you get the instant answer if everything actually builds or if something has been messed up.
I come from the mindset that servers should be designed to perform a specific task. An Active Directory Controller, for example, shouldn't double as a SQL sever.
From the prospective of resources available, it becomes difficult to balance the load between multiple server applications. A build server performing a build, for example, would affect performance of any other services on the box. It's likely that your build server will be used to build many different projects. Compilation and the plethora of tasks associated with a typical build (e.g., code analysis, unit testing, etc.) are expensive and CPU/disk intensive operations.
Additionally, have you ever noticed how your desktop becomes slower and less stable through time? This is often due to the of the number of applications that you install. Added dependencies and increased memory consumption will negatively impact the reliability of your servers.
Servers should be left clean and be designed to perform their specific task with as few interruptions as possible.
As an exercise ask the manager what machine would be suitable for being a build server? His machine? Another developer's machine? The cost of running that process on a developer's box would be bad.
For argument's sake, let's allow that a developer would run that on his/her machine. That is still probably a net positive over not having a build machine.
In a short time I suspect the manager and the team will realize a new machine is needed.
In spite of the Spolsky article referenced by someone else, the build machine does not have to be the fastest box... It can be a cast-off, second hand machine.
Once the team sees and experiences the benefits of a build server they will make the natural jump to a dedicated machine. (if they don't, then it is time to run)
Some specific reasons for it (As others have said)
Reproducibility and stability of the builds. It is imperative that the builds be consistent and repeatable. There is significantly more control over a build server than all the various developer machines. This allows developers to try Beta dev tools, etc without affecting a release/build.
Efficiency - using a dedicated build server frees up the CPUs of developer machines for developers.
Set your build server up on his PC and then use it for continuous integration builds until he understands why it needs its own server ;)
I give it an hour before he's on the phone to your hardware supplier to get you a new server.
Does "Continuous Integration" mean anything to your manager? That would be my suggestion as that is the primary reason for having a dedicated build machine, also it can hold the codebase for another use of a separate machine.
You want your build to run as fast as possible, especially if you are doing continuous integration or if you have a large build process. We've recently started fighting with our IT department because the servers we use for building and testing are getting too slow. This is mostly because they have them all running as virtual machines and they've got too many virtual machines per host. Our complete build process (not CI build) is now taking over half an hour to run (most of this is deployment, not compile) and it's killing our QA staff as they have to wait entirely too long for a build.
Take the amount of time your build process takes to run (in hours), multiply that by the number of times per year it is run, then multiply that by the hourly rate of the people that sit waiting for the build to finish. In our organization that's in the tens of thousands of dollars. It certainly makes the case for spending a little on a build machine.