I have been having a on-going project to run multiple build controllers on a single VM. Today I needed to reconfigure a on of the controllers to point at a different TPC. You have to do this the correct way to avoid problems.
My error log was full of
_Http communication failure:
_Exception Message: Cannot listen on pipe name ’net.pipe://build/ServiceHost/1’ because another pipe endpoint is already listening on that name. (type AddressAlreadyInUseException)
It all boiled down to the fact I ended up with two controllers trying to use the same URI, in my case
vstfs:///Build/ServiceHost/1
The number at the end of this URI is assigned when the controller is registered with a TPC. If, as I did, you just stop a controller and edit its properties to point at another TPC and restart it, it is possible to end up with two controllers on the same box trying to use the same ID.
The simple fix is to unregister the build controller and the register it with the new TPC as needed. This will cause the machine to be scanned and new, empty ID chosen for the URI. As as detailed in Jim Lamb’s original post.
As a side effect I also saw errors in the log saying custom activity assemblies could not be loaded due to permission errors. This all turned out to be that the custom activities are stored in
_C:Users[tfs build account]AppDataLocalTempBuildAgent[agent ID] _
So if two agents have on the ID, even if one’s parent controller is failing to load fully, it will tend to lock the files for the other controller. Again this was fixed by registering the controller and agents in the correct manner