7
votes

I am using Visual Studio 2013 and Team Foundation Server 2013. I have these, as well as the Build Controller/Agent, running on my personal computer, called "FUSROHDAH".

My goal is to take a build generated by the TFS Build Agent and open it for debugging in Visual Studio, and have it leverage the source indexed PDB to access the source code from the TFS source control system so that I can step through the code. I have studied several informative articles about PDB's and source indexing, including:

Ed Squared's article on Source Server and Symbol Server Support in TFS 2010

John Robbins' article about PDB files

I also watched John Robbins' very excellent video on WintellectNOW which discussed a lot of the nuances of setting up the symbol server, source indexing.

However, despite several days of hair pulling, I haven't been able to get this working yet.

I've set up TFS for continuous integration. Here are my settings:

In Build Definition->Build Defaults, I have set Staging Location to "Copy build output to the following drop folder (UNC path, such as \server\share)":

\\fusrohdah\builds (this equates to c:\builds on my machine)

Build Definition->Process Template Settings:

Path to Publish Symbols: \\fusrohdah\symbols\ (this equates to c:\symbols on my machine)

I notice that the Default Process Template in TFS 2013 looks different from the articles discussing TFS 2010. In Ed Squared's article, there is an option for "Index Sources". In TFS 2013, this setting is gone, and in the instruction text, it says "Specify the path to the symbol store share. When this value is set, source indexing is a part of the build." So I assume that I have source indexing running on my builds, by simply specifying this location.

So I take a simple console application HelloWorld and I perform a series of changes and check-ins. I observe the builds are published to the builds folder as I would expect, with an EXE and PDB file side by side.

So I want to take an older build and debug it in Visual Studio, and step through source code obtained from the TFS source indexing. I open the EXE in Visual Studio and hit F11 to launch the console application and begin stepping into the code in the Main() procedure. But, when this happens, I get this message:

--------------------------- Microsoft Visual Studio --------------------------- Source file: C:\builds\2\LocalTestProject\HelloWorld\src\HelloWorld\HelloWorld\Program.cs

Module: C:\builds\HelloWorld\HelloWorld_20140722.6\HelloWorld.exe

Process: [6016] HelloWorld.exe

The source file is different from when the module was built. Would you like the debugger to use it anyway?

This seems to be the crux of my problem. My understanding is that when Visual Studio reads my PDB file, it should execute TF.exe to obtain the correct version of the source code from TFS, and it seems to be failing to do this. I used PDBStr.exe to look at the PDB file published by the build, and nothing seems amiss:

c:\builds\HelloWorld\HelloWorld_20140722.6>pdbstr -r -p:helloworld.pdb -s:srcsrv

SRCSRV: ini ------------------------------------------------
VERSION=3
INDEXVERSION=2
VERCTRL=Team Foundation Server
DATETIME=Tue Jul 22 23:04:51 2014
INDEXER=TFSTB
SRCSRV: variables ------------------------------------------
TFS_EXTRACT_CMD=tf.exe view /version:%var4% /noprompt "$%var3%" /server:%fnvar%(
%var2%) /console >%srcsrvtrg%
TFS_EXTRACT_TARGET=%targ%\%var2%%fnbksl%(%var3%)\%var4%\%fnfile%(%var5%)
SRCSRVVERCTRL=tfs
SRCSRVERRDESC=access
SRCSRVERRVAR=var2
VSTFSSERVER=http://fusrohdah:8080/tfs/DefaultCollection
SRCSRVTRG=%TFS_extract_target%
SRCSRVCMD=%TFS_extract_cmd%
SRCSRV: source files ---------------------------------------
C:\Builds\2\LocalTestProject\HelloWorld\src\HelloWorld\HelloWorld\Program.cs*VST
FSSERVER*/LocalTestProject/HelloWorld/HelloWorld/Program.cs*18*Program.cs
SRCSRV: end ------------------------------------------------

I observe in the Output window that Visual Studio thinks it has successfully loaded the symbols when I'm debugging my EXE. I do not see a message indicating that it ran TF.exe, however, so I believe it is failing to run this to obtain the source.

I did verify in Visual Studio that I have "Enable Just My Code" UNCHECKED, and "Enable Source Server Support" CHECKED, along with "Print Source Server diagnostic messages to the Output Window".

Question: how do I know if Visual Studio is attempting to run TF.exe to obtain source code from TFS like I would expect?

Aside from that, I'm not sure if my problem is with the build configuration, symbol server/source server configuration, or my approach to attempting to debug using the aforementioned pieces. I will pledge fealty to the wizard who can illuminate my path for me!

1
have you set the location of your symbol server in Visual Studio. tools > options> debugging > symbols?Just TFS
@JustTFS: Yes, I set my _NT_SYMBOL_PATH environment variable to: SRVC:\MYSYMBOLS\PUBLIC*\\fusrohdah\symbols;SRVC:\MYSYMBOLS\PUBLICreferencesource.microsoft.com/symbols;SRVC:\MYSYMBOLS\PUBLIC*msdl.microsoft.com/download/symbolsJim Comiskey
Have you added the symbol path in visual studio? That have worked for me, and I have even done remote debugging using this setup.mikanyg
Any updates on this topic? I have the same problems with TFS Build vNext and Visual Studio 2015. In the output window I read "source file has changed. It no longer matches the version of the file used to build the application being debugged." and if a breakpoint get hit, everything is working fine except the fact that I can not read variable content. In the watch window I read: Internal error in the expression evaluator. How is that supposed to work?timtos
I am using Visual Studio 2013 with Team Fundation Server 2012 and was able to perform this. I hope this is not a regression from newer versions you are using of either or both.Louis

1 Answers

0
votes

Have you tried removing the build server working directories before debugging ? If a debugger can find the files denoted in SRCSRV on disk it will take precedence over getting them with tf.exe (even if they are the wrong version match). Only if it can't find the files on disk or in cache, it will try reference the source server. Because you are performing this on the buildserver, the locations denote a later version of the sources.