Jelle Druyts

I've just published another update to my guide on Setting up Source Server for TFS Builds, since the Debugging Tools for Windows now has built-in support for Team Foundation Server. So that means: no more third party downloads and an even simpler installation procedure! I've also updated the document to reflect all applicable versions of the tools you'll be using: Visual Studio 2005 and 2008, as well as Team Foundation Server 2005 and 2008.

Because I have been troubleshooting Source Server issues a few times as well, I also added a chapter on how to find out what's going on inside the Source Server indexing and what might be going wrong. Note that there is some Perl going on in there, so avert your eyes if you can't handle the look and feel of it (I know I can't)

For the full setup instructions, please refer to the original post on Setting up Source Server for TFS Builds.

Oh, and finally, my homie Pieter also posted a more detailed guide on how to set Source Server support up inside the Team Build script - and what's more important, what the invaluable benefit is of having a central reusable build script. Great job Pieter!

Just a quick note to let you know that I've updated my guide on Setting up Source Server for TFS Builds, since I just found out that there is an issue with Build Definitions that contain spaces. The fix is fairly easy though:

• In TFIndex.cmd (on the build server), remove the quotes around the %1 argument for SYMBOLS:

@call "%~dp0SSIndex.cmd" -SYSTEM=TF -SYMBOLS="%1" %*
@call "%~dp0SSIndex.cmd" -SYSTEM=TF -SYMBOLS=%1 %*

• In the Team Build Script (in Source Control), add XML-escaped quotes around the $(BinariesRoot) argument:

<Exec Command="&quot;C:\Program Files\Debugging Tools for Windows\sdk\srcsrv\TFIndex.cmd&quot; $(BinariesRoot)"
      WorkingDirectory="$(SolutionRoot)" />
<Exec Command="&quot;C:\Program Files\Debugging Tools for Windows\sdk\srcsrv\TFIndex.cmd&quot; &quot;$(BinariesRoot)&quot;"
      WorkingDirectory="$(SolutionRoot)" />

For the full setup instructions, please refer to the original post on Setting up Source Server for TFS Builds.

[Update 30/04/2008] Fixed issue for Build Definition names that contain spaces.

[Update 08/07/2008] Updated for new version of Debugging Tools for Windows; added Troubleshooting chapter.

[Update 05/08/2008] Updated "srcsrv.ini" file contents for new version of Source Server script (does not include cmd.exe anymore).

[Update 20/03/2009] Added troubleshooting part for "Illegal characters in path" error.

[Update 30/03/2009] Updated "Illegal characters in path" patch to also include the srcsrv.dll file (in addition to symsrv.dll).

I've read about symbol servers and source servers before (in John Robbins' excellent Debugging Microsoft .NET 2.0 Applications book, for example, and also due to the recent news that Visual Studio 2008 will support source-code debugging of the .NET Framework Libraries), but never really got around to trying them out since they seemed pretty complex to set up. However, I've recently set up a source server on a Team Foundation build server (twice!), and my eyes have now gone wide open: anybody who references assemblies built by those TFS build servers can now seamlessly debug them.

When an assembly is "source server-enabled", the pdb file will contain the full path and the exact version of the file in source control that was used to build that assembly. If the debugger then enters a method, Visual Studio automatically downloads that correct file, places it in a local cache, and opens it for debugging. This is super sweet!

Now the hard work is already done and available in the Debugging Tools for Windows, but there are some extra steps to take if you want to integrate this in a real Team Build (i.e. on the TFS build server instead of on a local machine) and it also lacks some additional information to get everything working. So I put together a full document that covers all aspects of setting up a source server, modifying the Team Build script, configuring the project files, and finally configuring the development machines.

The full document (PDF) can be downloaded here, and you can read the one-page summary that briefly covers the required steps below. I cannot recommend setting up a source server enough, it's free and takes less than an hour if you simply follow the procedure, and the advantages are - hopefully - obvious.

Setting up Source Server for TFS Builds.pdf (0,98 MB)

Note that this procedure works for both TFS 2005 as TFS 2008, and both VS 2005 as VS 2008.

Installing Source Server on the Build Server

• Install the Debugging Tools for Windows (at least the "Source Server" component)
• Install Perl (e.g. ActivePerl)
• In the tfsindex.cmd file in the Debugging Tools for Windows directory, change the last line to

@call "%~dp0SSIndex.cmd" -SYSTEM=TFS -SYMBOLS=%1 %*

• In the srcsrv.ini file in that directory, set MYSERVER to the exact URL of your Team Foundation Server (Application Tier)
• Add the full path to TF.exe (usually "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE" for VS 2005 or "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE" for VS 2008) to the system's Path environment variable
• Restart the "Team Build Service" (for TFS 2005) or "Visual Studio Team Foundation Build" (for TFS 2008) Windows service

• Add a new target to TFSBuild.proj to be run on "AfterCompile" that calls tfsindex.cmd:

<Target Name="RunSourceServerIndexing">
  <Exec Command="&quot;C:\Program Files\Debugging Tools for Windows (x86)\srcsrv\tfsindex.cmd&quot; &quot;$(BinariesRoot)&quot;"
        WorkingDirectory="$(SolutionRoot)" /> 
</Target> 
<Target Name="AfterCompile"
        DependsOnTargets="RunSourceServerIndexing" />

• Set the Debug Info in Project Properties / Build / Advanced to "full" (Debug configuration) or "pdb-only" (Release configuration)

• In Visual Studio / Tools / Options / Debugging / General: check the "Enable source server support" checkbox
• Create a new text file named srcsrv.ini in the Visual Studio directory (usually "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE" for VS 2005 or "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE" for VS 2008) that contains the exact following text:

[trusted commands] 
TF.exe view

I was having some trouble the other day with our Team Build server when building a project that is used by an open Visual Studio instance.

Our setup is that we build our enterprise framework on the build server and then copy it to a public share so it can be used by the client projects. Now when somebody is actively developing a project in Visual Studio that uses this enterprise framework, we receive something like the following error in the build log when building the framework:

Copying drop to final destination
Copying folder "\\BuildServer\Drop\Framework_20060530.2\Release" to "D:\PublicShare\References\EnterpriseFramework\Latest".
D:\Build\Team\EnterpriseFramework\BuildType\TFSBuild.proj(168,5): error : A task error has occured.
D:\Build\Team\EnterpriseFramework\BuildType\TFSBuild.proj(168,5): error : Message = Access to the path 'D:\PublicShare\References\EnterpriseFramework\Latest\EnterpriseFramework.Common.xml' is denied.

So the open Visual Studio instance on the developer's pc seems to keep a lock on the XML file (for IntelliSense) on the build server, causing the build to fail. Now I don't think it's very nice of Visual Studio that it locks the file, but apparently that's the way it is.

So here is the unclean (you won't catch me calling anything I do 'dirty' of course) workaround I used to get rid of this sticky problem. In the build script, right before copying the files to the public share, I execute the following task:

<Exec Command="net session /delete /y" />

This simply forces a delete of all connected client sessions, closing all the handles of the files that are opened remotely. Problem solved - as long as we don't have the race condition where somebody would lock another XML file just between that command and the actual copy, but what are the odds... The only minor side effect is that the opened Visual Studio instance loses IntelliSense for some of the files it had locked, but we can live with that. At least it's better than breaking the build, right?