Orcas Team Build: WCF web services replace .NET remoting

Buck Hodges

In Visual Studio Team Foundation Server 2005 (v1), the communication from the application tier (AT) to the build computer used .NET remoting.  This was the only component in Team Foundation Server that used .NET remoting, as all other communication used web services (see Team Foundation Server Security Architecture).

As part of the .NET 3.0 framework that shipped in the Vista timeframe (the Orcas framework is .NET 3.5 while VS 2005 shipped .NET 2.0, if you are trying to keep the version numbers straight), Windows Communication Foundation (WCF) introduced the ability to create web services that run without IIS being installed.  This is great because the build computer is a case where we’d like to use web services, but we didn’t want to require IIS on the build computer.

Moving to web services means that the communication from the AT to the build computer is now SOAP/XML over HTTP rather than a binary .NET protocol.  It also helped us improve our error handling, which is cleaner and easier with web services and can work the way it does in the rest of the product.  Going forward, it should help with versioning (the version of the service is based on the URL to the web service).

Moving beyond Orcas, we have bigger plans for the build agent (an Orcas build agent is a build computer running the build Windows service listening on a particular port — basically, a computer name and port pair).  Using WCF fits much better into those plans.

For a whole lot other reasons, a v1 build computer cannot be used with an Orcas (v2) Team Foundation Server (AT).  You must use an Orcas build agent with an Orcas AT.  Starting with the first beta of Orcas (it’s not in the March CTP), the build report will tell you if the build agent you specified is not an Orcas build agent.

If you want to manually determine whether a particular service on a build computer is using .NET remoting or WCF web services, you can simply telnet to it, type some random characters, and hit Enter twice.  The output is different and is shown below.  The first one shows v1 and the second v2.

c:\> telnet whidbey-buildcomputer 9191

.NET☺☻☻♥☺♥☺☺hServer encountered an internal error. To get more info turn on
customErrors in the server’s config file.

Connection to host lost.

c:\> telnet orcas-buildagent 9191

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Fri, 16 Mar 2007 20:23:18 GMT
Connection: close
Content-Length: 35

<h1>Bad Request (Invalid Verb)</h1>

Connection to host lost.

Buck Hodges Director of Engineering, Azure

Follow