An Interesting Team Foundation Server Side Effect

If you're familiar with the Domain Driven Design school of thought on software design, you're no doubt also familiar with avoiding the introduction of side effects into your class designs. Eric Evans defines the term to mean "Any observable change of state resulting from an operation, whether intentional or not, even a deliberate update." I stumbled across an interesting example of this term tonight as I was playing with Team Foundation Server. I created a new team project called 'Best Practices Proj - Multi Solution' on my TFS server 'VMC-2K3-TFS_TFS'. I performed the tests that I was trying to perform with no problem – all I had left to do was prove that everything still behaved normally in Team Build. Therefore, I created a new build type called 'Build 1' – and ran it. The build failed because of the following error.

System.Web.Services.Protocols.SoapException: TF10165: The workspace name VMC-2K3-TFS_TFS Best Practices Proj - Multi Solution Test_Build is not supported. It must be less than 64 characters, cannot end with a space or period, and cannot contain any of the following characters: "/:<>|*?

As you can see the TFS build targets will by default create a workspace by concatenating the build machine name with the team project name with the build type. Fortunately, the error message here was actually pretty descriptive – in my case, I exceeded the 64 character limit. Unfortunately, there was no mention of this downstream constraint when I created my team project – and if you have ever tried, you know that it is not a trivial thing to rename a team project. Therefore, the moral of the story is to avoid long names in your TFS projects. Also, if you do find yourself in this predicament, you can get around it by declaring the name of the workspace to be used by Team Build yourself. You can do this with the following property declaration.

<PropertyGroup>

    <WorkspaceName>my_custom_workspace</WorkspaceName>

</PropertyGroup>