Delete your Builds or suffer the OOM Exception!

I have been working on an issue recently where Visual Studio 2010 can crash while interacting with Team Foundation Server (TFS). What happens is that certain actions in the IDE send a request back to TFS to enumerate all of the builds associated with a project. If you have a large number of builds on the server, the results of the query can consume more memory than might be available on the client machine and result in an OutOfMemory (OOM) Exception being thrown. In this particular case, my customer experienced this while trying to associate a failed unit test to a new bug work item. The problem occurs when the user was trying to create the work item through the right-click context menu of the bug. The IDE would issue it's query, chew up memory for about 5 minutes and then throw the OOM Exception.

There are a couple of way you can work around this. 

1) The most immediate way would be to create the new work item from team explorer and then attach the trx file (available in the test results folder) to it.

2) Clean up your old builds as part of your release process. Once you release, you probably don't need all of your builds stored in TFS. While you may wish to keep your main releases, I would recommend deleting any timed (daily/weekly) or continuous integration (CI) builds. This will keep the number of builds lower so this OOM Exception can be avoided.

The number of builds that triggered this was close to 18,000 for the project. If you would like to know how many builds you have currently in TFS for your project, you can simply run the following SQL statement against your TFS Collection database:

SELECT COUNT(Deleted) FROM [Tfs_DefaultCollection].[dbo].[tbl_Build] WHERE Deleted=0

Delete those Builds!!!