Yet another post about Team Build and the 260+ char limit

So this is definitely not a new topic and there has been lots of post about it. But I’d like to make sure that you don’t find yourself in the situation where you receive the following error message:

”The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.”

As many already have stated this is not a limit in Team Build but a Windows limit, you can read more about that here.

Even though many devs out there are brutally aware of this hard limit I tend to see the same mistakes appear at customers over and over again.

Lets start out with some basics:

  • Don’t create source control folder hierarchies that mimic your namespace naming or any other convention. That leads to deep hierarchies that will get you closer to the 260+ limit.
    image
  • Instead try to keep your source control hierarchy as flat as possible, use the solution folders feature in Visual Studio to represent your hierarchy instead.

    image
    See how the Source and Tests hierarchy are used as Solution Folders instead in Visual Studio without creating any extra folder level in source control:
    image

  • Keep your workspace folder mappings short and consistent like “C:\ws\”
  • Keep your namespaces short and sweet and remember that you don’t need to name your solution/project folders the same as your namespace (although I know it simplifies the daily work a lot Blinkar)

And here are some advanced strategies:

  • Use $(BuildDefinitionId) instead of $(BuildDefinitionPath) when you configure your build agents.
    image
    The picture below shows the output in folder structures between these two approaches using the same build definition but different agent settings. The pictures are taken from a TFS 2010 installation for TFS 2008 there is no $(BuildAgentId) folder.
    image
  • In TFS 2008 shorten the “SourcesSubdirectory”, “BinariesSubdirectory” and “TestResultsSubdirectory” configuration in the TfsBuildService.exe.config.
  • In TFS 2010 shorten the assignment in the string for the “Initialize Sources Directory”, “Initialize Binaries Directory” and “Initialize TestResults Directory” in your DefaultTemplate.xaml as the picture shows:
    image
  • In TFS 2010 if you’re using the UpgradeTemplate.xaml you can substitute the name for the directories in the Advanced section like the picture shows:
    image
  • Create a custom Check-In policy that prevents users from checking in structures in source control that are longer then some number set by your administrator. Read more about it here.

This should prevent you from hitting the 260+ hard limit for a while but It’s no silver bullet unfortunately so I hope that a more complete solution will rise soon.

Enjoy,

Hugo

Building and Unit Testing .Net 4.0 with Team Build 2008, the correct order

I’ve been helping my customer setting up .Net 4.0 build servers lately as you may have read in my previous post. In the previous post, I listed my challenges getting .Net 4 assemblies to build and unit test with Team Build 2008 so I thought It would be time to share the correct order to get the stuff working!

  1. Install Visual Studio 2010 Premium
  2. Install Visual Studio Team System 2008 Development Edition
  3. Install Visual Studio Team System 2008 Service Pack 1
  4. Install Team Build 2008
  5. Install Team Build Service Pack 1
  6. Configured Team Build 2008 to use MSBuild 4.0 instead of MSBuild 3.5. To do this edit %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSBuildService.exe.config and set the MSBuildPath property to C:\Windows\Microsoft.NET\Framework\v4.0.21006\

That should do it! And if you install your build server in that order you won’t get the following error:

  • MSBUILD : warning : Visual Studio Team System for Software Testers or Visual Studio Team System for Software Developers is required to run tests as part of a Team Build
  • And you won’t replace the Microsoft.TeamFoundation.Build.targets with an incorrect workspace pattern:
    TFS Build 2008:
    $(COMPUTERNAME)_$(BuildDefinitionId)
    After VS 2010 installation:
    $(COMPUTERNAME)_$(BuildDefinitionId)_$(BuildAgentId)

Hope this summarizes how to install a build server that builds and unit tests .Net 4.0 applications with Team Build 2008.

Cheers!

Hugo

How to configure an automated test run with TFS 2010 and Test Manager

Some of you may have read my earlier post on the associated automation in TFS and Test Manager here. I got some comments that made me realize that more people could benefit from a complete step by step guide on this subject. As such this post will be very long but with a lot of pictures so I hope you stick with me.

Environment

First of all you’ll need a TFS environment, I downloaded my environment from Brian Keller here and all the screenshots you’ll see will be from Brian’s image.

Test Controller

You’ll need to start a Test Controller and register team project collection controller like so:

Test Controller

Configuring an automated Test Environment

To be able to run automated test runs we need to configure an automated test environment first. Startup your Test Manager and change to the Lab Center by clicking on the dropdown:

Testing Center - Lab Center

In the Lab Center click on the Controllers tab marked in red:
Controllers Tab

Make sure that your Test Controller shows up and has the status Ready:
Controllers Tab 2

Next step is to return to the Lab Tab marked in red and configure an Environment:

Lab Tab

On the New dropdown choose “New physical environment” like such:

New physical environment

Give your Environment a good name following your specific naming conventions and make sure that the Controller is correctly assigned. Click the button “Next” when you’re ready.

New physical environment - Name and location

On the “Machines” page click on your controller and then click on the button “Add to environment” marked in red.

New physical environment - Add to environment

As you do that your machine will appear on the left side of the screen. To continue you need to give the machine a specific role to make it easier for people to understand the role of the machine. I gave the machine the “Server” role like the picture below. When you’re ready should be able to click the next button.

New physical environment - Edit Role

On the “Machine Properties” page you could fill in more details regarding your machine but I simply skipped this step for now and left it clean.

New physical environment - Machine Properties

On the summary page I just clicked the Finished button and got on with next step.

New physical environment - Summary

When you’re finished make sure you see a green ready symbol like so:

Environments - Ready

Now we need to configure our automated test settings by clicking on the “Test Settings” tab marked in red below:

Test Settings Tab

Click the “New” button to create the automated test settings:

Test Settings Manager - New

Give the test settings a name, description and make sure that you choose automated in the selection section. Click the “Next” button when you’re finished.

image

On the Roles page make sure you click the role you choose earlier when you created your environment, for me that would be the “Server” role, otherwise you will not be able to click the “Next” button. Automated Test Run - Roles

If you have several roles you’ll need to chose which one you’re going to use for your automated tests, In my case I didn’t need to change this as I have only one role.

Automated Test Run - Select Roles

Click the “Next” button when you’re done.

On the “Data and Diagnostics” page configure anything you need and click the “Next” button, In my case I left all the defaults and clicked the “Next” button.

On the “Advanced” page you can configure even more advanced configurations, in my case I just clicked the “Next” button until the Summary page appeared.

image

So click the “Finish” button and lets go on with this adventure. Your result should be another entry in your Test Settings list:

Test Settings Manager - Automated

Turning the manual test into automated in Testing Center

Lets go back to the Testing Center by clicking the dropdown like so:

Switching back to Testing Center

Make sure you’re on the “Plan” tab and click the “Properties” link marked in red below. Here I’m assuming that you already have created a new suite, if you haven’t you should read this post.

Properties

On the somewhat huge properties page (you can easily get overwhelmed with all that information but I’ll lead the way) you should make sure that you choose your test settings in the Automated runs section, in my case I chose “Automated Test Run” created earlier.

Test settings - Automated Test Run

Next you choose your Test environment, in my case I chose “Automated Test Environment” created earlier.

Test environment - Automated Test Environment

Next you’ll have to assign a build for the automated tests. Assuming that you already created a build in this step otherwise you’ll need to create one. The section you’re looking for should look like so:

Builds

That’s it now click the Save and Close button and lets test this baby…

Change to the “Test” tab and start your automated test cases with the “Run” button:

Run Tests

If you’ve done your job right you should see the following very nice summary page:

Test Run Summary

Hope this will help someone out there with this rather straightforward but long blog post.

Cheers!

Hugo