1. The command line arguments are actually passed to msbuild.exe as part of a dynamically-generated msbuild.rsp file. So, if you specify /p:SomeProperty=SomeValue, the property is global and would be available in all of the projects.
2. I'm not quite sure that I understand the question. You can add customization via the tfsbuild.proj file. You can register a web service to get notification via a BuildCompletionEvent (use bissubscribe to register).
3. We don't show that in the GUI. We didn't feel that there was a lot of value in viewing the build agents used to run builds, so we didn't add a column for it in the display. That information is stored in the database, if I remember correctly, so you could
write something using the build client API that would show you that.
4. Yes. There's a new build client API in Orcas. The VS GUI was written on top of that API, and it's a public API.
Leadfoot, that's a difficult question to answer correctly. The fundamental question of value is directly tied to your statement about the integration. If the rich integration of work item tracking, source control, build automation, test automation, reporting,
Visual Studio, and Office helps you get more stuff done in less time, then Orcas is worth the time effort. However, if you compare the individual features in isolation there's not so much motivation. We are really focused more on excelling as an integrated
product and getting deeper in each of the feature areas over time (as compared to going deep in the areas and then trying to glue them together later).
1. Yes, you are correct on the first question. In Orcas, though, there is no way to specify that it should automatically pick an agent from a pool rather than specifying an agent (either the default for the build definition or picking one in the Queue Build
dialog). It is something we are looking into for the release after Orcas.
2. There isn't an equivalent to CCTray in the box with Orcas, but we are considering creating one as a power tool for Orcas (and then shipping it in the box in the release after Orcas).
3. Yes, the sources in the workspace used by the build are labeled as part of the build process.
4. Adding additional steps is straightforward. For FXCop, there's either the ability to run the product version in VSTS for Developers, which is called code analysis, that requires VSTS for Developers to be installed on the build machine. For the others,
you may be able to find custom msbuild tasks that others have built, or you may build one yourself. The easiest thing to do is to use the Exec task that's built into msbuild, but then you want get any reporting from that.
Integrating the information into the warehouse should simply require that you write a custom task that runs the tool as part of the build and calls the necessary build APIs to report the results.
You are right that you generally want the build machine to be as clean as possible, with nothing unnecessary installed on it. However, if you want to run unit tests or code analysis, you'll have to install VS Team System for Testers, Developers, or the Suite
to get those features. So unfortunately, it's not always possible to avoid installing VS.