Many Visual Studio project types are not supported by MSBuild - setup projects, reporting projects, etc.  As such, the typical guidance for building these types of projects from within Team Build has centered around invoking devenv (the IDE) using an Exec task or some other custom MSBuild task.  I was investigating a post on the Team Build forums today, and discovered to my surprise that much of this guidance has been slightly out of whack...  In particular, I had never read the following usage message emitted from devenv:

The first argument for devenv is usually a solution file or project file.
You can also use any other file as the first argument if you want to have the
file open automatically in an editor. When you enter a project file, the IDE
looks for an .sln file with the same base name as the project file in the
parent directory for the project file. If no such .sln file exists, then the
IDE looks for a single .sln file that references the project.
If no such single
.sln file exists, then the IDE creates an unsaved solution with a default .sln
file name that has the same base name as the project file.

Note the bolded section - if you pass devenv a project file instead of a solution, it will attempt to locate the solution that contains that project and build it!  That is, if the solution contains more projects than just the one specified, these additional projects will end up getting built.  As such, rather than doing something like:

> devenv foo.csproj /Build "Release"

...you should probably do:

> devenv foo.sln /Build "Release" /Project foo

This will ensure that only the project "foo" is built, rather than all projects within foo.sln.  (Note that when using the /Project syntax only the name of the project is used - don't include the extension.)

One other tip - you'll typically want to specify either just "devenv" or "devenv.com", rather than "devenv.exe".  "devenv.exe" doesn't generate any output, and will make debugging any issues pretty complicated.  Additionally, "devenv.exe" sometimes spawns GUI (e.g. to display the usage statement) which will hang Team Build, since it runs as a non-interactive NT service.