Using Symbol Server/Source Indexing to debug a build in Visual Studio - tfs

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!

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.

Related

BuildActivity ignores ToolsVersion

I have a Continuous Integration Build Running on a BuildAgent which I can not get working properly. I recently changed our codebase to C# 6.0 and changed the projects to ToolsVersion 14.
I did install Visual Studio 2015 on the Build Server (TFS 2012). If I do now check in the C# 6.0 code the build fails on the first project ("$" is unexpected or something")
The BuildTemplate is "DefaultTemplate.11.1"
If I check the log files the build calls the wrong csc.exe (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Csc.exe)
if I do start the MSBuild/14.0/Bin/MSBuild executable with the project without any switches the Build succeeds. Why does the TFS BuildAgent not use the ToolsVersion and how can I get TFS 2012 to build my Visual Studio 2015 solution
If I add the MSBuildArgument /tv:14.0 it still fails. As it calls th Version 12 of MSBuild which is part of the .NET 4.6 RC Framework which ships with Visual Studio 2015.
Changing the ToolsPath of the MSBuild Activity does get the Build working but spits bullets if I try to run my UnitTest. I get aMissing dlls "Microsoft.VisualStudio.TestPlatform.Utilities.dll" exception. (VS2012 is installed as well on the Build Server).
UPDATE:
I do now get a different error with my unit tests:
TF900548: An error occurred publishing the Visual Studio test results.
Details: 'Method not found:
'System.Collections.Generic.IEnumerable<System.String>
Microsoft.VisualStudio.TestPlatform.Utilities.InferSettingsHelper.MergeRunSettingsAndFindCompatibleSources(Microsoft.VisualStudio.TestPlatform.ObjectModel.Architecture
ByRef,
Microsoft.VisualStudio.TestPlatform.ObjectModel.FrameworkVersion
ByRef, System.String, System.String,
System.Collections.Generic.IDictionary`2<System.String,System.Collections.Generic.KeyValuePair`2<Microsoft.VisualStudio.TestPlatform.ObjectModel.Architecture,Microsoft.VisualStudio.TestPlatform.ObjectModel.FrameworkVersion>>,
System.Xml.XPath.IXPathNavigable, System.String ByRef)'.'
For those of us not living inside build templates every day here's the steps that got it working for me:
First find the template associated with your build (if you already know where to find it skip a couple steps).
Just right click the build definition and select Edit build definition
Select the Process tab and you'll see the name of the template (quite likely to be DefaultTemplate if you haven't customized it). On the far right click Show details to see the path for the template.
Go to the Home tab under Team explorer and click Source control explorer
Find the template file and double click to edit it. It should come up in a graphical view like this. Scroll till you find Run MSBuild for Project
Click on this item which will immediately bring up properties
Click on the little icon on the right - don't try and type it in because it'll probably explode and crash Visual Studio.
Enter IN QUOTES the following "C:\Program Files (x86)\MSBuild\14.0\bin"
NOW FOR THE MOST IMPORTANT PART
For me the Run MSBuild for Project was in TWO places.
So I just repeated the above steps in both places, and then after I checked in the .xaml file my build FINALLY worked fine.
You may need to recycle the agent / controller from within the TFS tool.
Edit template change msbuild activity ToolPath to "MSBuild/14.0/Bin/MSBuild"
See answer by Marson.
Using the TfvcTemplate.12.xaml build process template with the /tv:14.0 Build argument worked for me.
use msbuild aruguments /p:VisualStudioVersion=14.0

Could not copy. The process cannot access the file because it is being used by another process

I am getting the following error when running my build on Visual Studio Online (using the built-in Build Controller):
C:\Program Files
(x86)\MSBuild\14.0\bin\amd64\Microsoft.Common.CurrentVersion.targets
(3962): Could not copy
"d:\a\src\MySolution\MyProject\Trunk\packages\Microsoft.Data.Edm.5.6.4\lib\net40\Microsoft.Data.Edm.xml"
to "..\Build\bin\Release\Microsoft.Data.Edm.xml". Beginning retry 1 in
1000ms. The process cannot access the file
'..\Build\bin\Release\Microsoft.Data.Edm.xml' because it is being used
by another process.
It is never the same file either but it seems to always be either an xml or dll from the packages folder.
EDIT: I'm not sure if it is worth mentioning, but I do have multiple workspaces and multiple build definitions using this repository.
I found the problem. Completely unrelated to the error above.
I went into the msbuild log files and found this:
Failed to produce diagnostics extension's config for
MyRole\diagnostics.wadcfgx. Error : Could not find a part of the path
'd:\a\src...\MyRole\diagnostics.wadcfgx'. Done Building Project
"d:\a\src...\MyCloudProject.Cloud.ccproj" (Publish target(s)) --
FAILED.
I was missing a file in source control.
I do wonder why this error did not bubble up into my build summary. And where did that initial error come from?
I am using TFS with Using Visual Studio 2013 and have been able to work around this issue by closing all open documents that I want to check-in (seems VS locked itself out) and/or resolving conflicts. The error message is sufficiently vague so as to be useless as to the actual cause of the check-in failure.
Update 02 November 2016:
I'm not sure why VS 2013 and TFS don't play nice together via the Team Explorer Check-in Pending Changes button, but it consistently fails to launch the conflict resolver, a key piece of the check-in process.
The following works for me on VS 2013 and TFS hosted on a SQLServer Express 2014 database:
1. Launch the Source Explorer: Team Explorer tab -> Source Explorer
2. Navigate to your solution repository
3. Then proceed to do the following for each project that you want to check in:
a. Right click project
b. Check in pending changes
c. Resolve conflicts and repeat steps 3a and 3b until no pending changes remain for the project

How do I modify a VS Build Workflow if VS can't find any custom DLLs it uses?

I'm using TFS Server 2010.
In my source I have a folder called BuildProcessTemplates. This has a child folder called Custom Assemblies.
Now, when the build runs, it happily loads the DLLs in the Custom Assemblies folder and does its thing.
I need to modify the .xaml file that defines the workflow of the build. If I double click on the .xaml file VS tries to open it but throws an error saying it can't find certain types that I know are defined in the DLL that is in the Custom Assemblies folder.
The workflow is told where to find these types when the build runs by Build Controller as it is defined as a property in the TFS Admin Console.
So, how on earth do I get VS to open my .xaml file properly? How do I let it know where to look for the DLL? I've tried moving all of the files in Custom Assemblies in to the same folder as the .xaml file, but that didn't help.
Clearly I'm missing something; I just don't have a clue what it might be.
You normally create a C# Project (Unit Test is easiest because it is pretty bare).
When you have you project you then need to:
Add the XAML as a File,
Add the Custom Activities DLL's as references.
Add the relevant TeamFoundation* references from the GAC (make sure the TFS version matches - 2010 = v10, 2012 = v11).
Also, I always open our TFS "Build Project" with VS version that matches our TFS Version, I find it keeps the number of problems down.
There's a great series of posts from Ewald Hofman here, that go through the process - I find it a bit dated, and that the Wrox Professional TFS 2012 book does a better job of explaining it, if you can get a copy.

Why does my TFS workspace path keep remapping itself?

We're using Visual Studio 2008/TFS 2008.
We have a small team of developers and for some reason, periodically, when any of us "Get Latest," one of our paths remaps to a different path on it's own. This causes the "Get Latest" to start deleting files, because the path has changed. It's the same path every time that gets remapped to the wrong path.
Where are workspace definitions stored?
Is there something we may have checked into TFS that's causing this?
I have had this happen when I get while opening a solution. If the solution contains relative paths to other projects not under it's folder, that are mapped differently in your workspace, the GET will tell me it's remapping to account for it. Problem is the decisions that it makes are completely wrong.
The only way around it was to ensure that all developers use the same structure that sourcec control uses and havev that represented in each workspace.
Getting there was a pain though. basicly everyone had to delete all local copies of all files, redo workspace, CHOOSE NO TO 'GET' WHEN WORKSPACE CHANGED, close VS, open, GET LATEST.
The reason for that was if copies of projects exsisted local, even if those projects were NOT open, the GET would still be wrong. This was frustrating, because when checking for differences in those projects with latest there was no change, but when opening the solution that contained that project, dll references in that project would auto change. At that moment, no changes are pending on ANY file. But after building the changes would persist and cause the next get to be off again...
I'm sure this is all wrong, but that's what happened to us this week.
This is not normal behavior - sounds like something is going funny. Just wanted to check - all you are doing is simple get's from Source Control explorer correct? Also - all of you are on different machines? (I.e. you are not sharing a virtual PC image or anything where multiple machines have the same name)
One think I would check is to go to File, Source Control, Manage Workspaces and look at your working folder mappings both before and after the get and see if anything is changing. It shouldn't - if it does this might give us a clue as to what is happening.
You can also try clearing your workspace cache and remap it:
SET AppDataTF=%USERPROFILE%\Local Settings\Application Data\Microsoft\Team Foundation
SET AppDataVS=%APPDATA%\Microsoft\VisualStudio
IF EXIST "%AppDataTF%\1.0\Cache" rd /s /q "%AppDataTF%\1.0\Cache" > NUL
IF EXIST "%AppDataTF%\2.0\Cache" rd /s /q "%AppDataTF%\2.0\Cache" > NUL
IF EXIST "%AppDataVS%\8.0\Team Explorer" rd /s /q "%AppDataVS%\8.0\Team Explorer" > NUL
IF EXIST "%AppDataVS%\9.0\Team Explorer" rd /s /q "%AppDataVS%\9.0\Team Explorer" > NUL
Ok i got it. Here is the solution.
First of all install Visual Studio 2008 SP1.(i suppose you have VS 2008 and Team Explorer already installed).
Now launch Visual Studio 2008, Goto Source Control and delete workspace.
Create a new workspace and make a source control folder to local folder mapping.
Click Ok. When it asks "Workspace has been modified, you you want to get latest", Select NO.
Now Close Visual Studio 2008.
Reopen Visual Studio 2008 and go to source control and Get Specific (with both check boxes checked for overwriting files).
If you have a asp.net web based solution, now is the time to create application pool, configure website in IIS, set proper authentication and authorization. Otherwise its optional!
Now goto the appropriate folder in source control and double click the solution file. You may also open the solution by double clicking the solution file in your local folder but i find it easier to open the solution from source control.
Doing the above step, if your website is configured, Visual Studio 2008 will automatically detect your website that you had setup and prompt you to confirm it. Click ok.
It will contact the source control server to see if synchronization is necessary or not. If you have a number of projects in your solution, you will observe the file-get progress bar quickly blink across your screen and your solution will be setup in minutes.
The real problem is of Visual Studio 2008 Service Pack 1. Without which TFS mapping gets corrupted. IF SP1 is installed and the above guide is followed there will be no problem.
The Workspace definitions are stored on the server.
If you go to the command line and type "tf workspace", you will see the definition of your workspace.

Does any tool exist to help Sync a directory with TFS?

When using TFS with a tool outside of Visual Studio (Specifially ORMS), modifications to the project file to include a new file will not cause the file to be added to source control.
Does anything exist that could potentially say "Warning: You are about to check in change to a project file which include a file which is not versioned"
In addition to Martin's answer, the latest release of TFS Power Toys includes:
"Windows Shell Extension (NEW!)
Allows core version control operations within Windows Explorer without using Team Explorer."
So you may just be able to commit those new files without having to fire up Team Explorer or use an MSSCCI compliant source control client.
Not quite, however you might want to download the TFS Power Tools and check out the command line utility tfpt.exe.
The "tfpt online" and "tfpt treeclean" might be most useful to you when working outside of an integrated TFS client. tfpt online will look for files in your local directory that are not under version control, treeclean will show you files in your local directory that are not under version control so that you can remove then if they are not required.
Good luck,
Martin.
One gotcha I've found using tfpt online is that it doesn't always pick up changes unless you use the /diff switch. That one caused us all kinds of headaches with our automated build until I realised what was happening!

Resources