Does TFS make both Symbol and Source server? - visual-studio-2010

I have read “What is the difference in TFS 2010 between a source server and symbol server?”
I have tried to set up my TFS build definition to generate source and symbol server.
Like this:
However, for me the result looks not like a proper symbol server.
When I open a crash dump, I still need to set symbol path to the correct drop folder where the dll’s (and also another .pdb ) reside.
In the selected “Path to publish Symbols” I see folders for the .pdb, but not for the .dll.
To be able to debug a dump I know that also the dll’s are needed.
Therefore I suspect my tfs to make only a source server, how can I then also have a symbol server.

TFS is only a Source Server. By specifying a shared path as your symbols store you setup for yourself a Symbols Server where Tfs Build publishes your projects' .pdb files to. The Symbols Server does not contain the binaries. The binaries should either be on the machine where you debug your application or from the build drop location.

Related

Unable to access symbols published in VSTS Symbol server from visual studio

I'm able to successfully publish symbols to the VSTS symbol server as part of the build execution.
Followed this link to setup visual studio and everything good until this point. My symbol settings shown below:
When trying to debug, visual studio hits VSTS symbol server but return error message “Cannot find or open PDB file”
Below is the symbol load information provided by visual studio after trying to fetch from VSTS symbol server
As of November 15 2017 Visual Studio Online (also now known as Azure DevOps) the Index Sources and Publish Symbols build step handles the new portable PDB's create by dotnet build
You should tick Publish symbols and select your Subscription. The free tier has 5 users. You need to assign each user access to symbol server.
Ticking the Index Sources check box makes no sense though as the source files are on the build server, usually in an obscure location such as C:\agent\_work\34\s\... which will not match your local (or network path) to the source files.
To help Visual Studio find the source files you can do this... (you can avoid this by using SourceLink as described below)
Select the solution in Solution Explorer and then choose Properties from the shortcut menu.
Under the Common Properties node, choose Debug Source Files.
Click the folder Tools/ Options/ Debugging/Symbols folder icon icon. Editable text appears in the Directories containing source code list.
Add the path that you want to search.
When you start debugging all the symbols will download and you can step into the source code now.
This does NOT require disabling just my code and you do not need to enable source server either.
Unless you are using, or would like to use source server. It is pretty easy to do now by adding a few packages...
With AzureDev ops you can modify your build pipeline to make use of soruce files stored in GIT byt following this guide.
The prerequisite is .NET Core SDK 2.1.300 or desktop msbuild version
15.7.
On your package project project you need to add NuGet package "SourceLink.Create.CommandLine" which will enable your build server (and your local build machine) to rewrite parts of the Portable PDB's without changing anything in the build pipeline.
You also need to add a package to the correct source control. As described in this article. - I am using VSTS so I just install "Microsoft.SourceLink.Vsts.Git" package (must enable Include Prelease as of writing now)
To verify this works all you need to do is build the project and look inside \obj\{config}\{tfm}\ for a file called *.sourcelink.json and has the correct URL's inside it.
Then the usual pack and publish you would do.
In Visual Studio you just need to enable
Enable Source server support
Enable Source Link support
You need to run the application built in the same build as the build to publish symbols to VSTS Symbol server, the identity will be different in the different builds.
You can find that there is the GUID (0CD368C47775439…) in the Symbol load information, also you can check the Publish symbols task’s build log, there is the GUID too. Within a build the GUIDs will be the same and the symbols will be loaded correctly during debug.
Did you enable Source Server Support in the VS.NET debug options ?
You might also uncheck 'Enable Just My Code' in the VS.NET debug options.
There's a blogpost that I've recently written where I explain setting up and using a symbol server; might find some tips that might help you with your problem.

Make "Go to definition" navigate to the .NET reference source

In Resharper, there's an option to navigate to sources from symbol files. If I enable downloading, the navigation works - I can step into the code of Console.Writeline and so forth.
However, I have already downloaded the entire reference source - is there a way to direct Resharper to that source, so it doesn't download unnecessarily?
I've configured the reference source according to the instructions on the site
It's not possible at the moment. Please vote/watch http://youtrack.jetbrains.net/issue/RSRP-126489
I was able to get this working with Visual Studio 2015 RTM and ReSharper v9.1.3 (and Visual Studio 2013). This is what I did...
NOTE: This is quirky. I'm not sure why, but sometimes the downloaded symbols have source code info in them and sometimes they don't. I had to repeatedly delete symbols from my cache and try to get the appropriate ones by attached the debugger to apps/websites and go to the Tools->Options->Debugging->Symbols and clicking Load All Symbols. I also did some source-stepping, and I had to copy the PDB files from my Symbol Cache into directories in the GAC and in C:\Program Files (x86)\Reference Assemblies. Finally, I went to the properties of the Visual Studio project and add F:\dd to the list of Reference Paths. I'm now able to right-click Navigate to Sources to most classes.
Short version:
You have to use http://referencesource.microsoft.com/symbols as your symbol server instead of the default Microsoft Symbol Server
The symbols expect to find the Reference Source files in F:\dd.
Delete all cached symbols so it pulls them fresh from the newly added symbol server.
Long version:
Configure Visual Studio according to the instructions found on the official .NET Reference Source site.
Go to Visual Studio's Tools->Options->Debugging->Symbols, stop using Microsoft Symbol Servers and use the Reference Source Symbol Server (http://referencesource.microsoft.com/symbols) instead.
Delete all of your cached symbols! The PDBs in your cache do not have any information about the source code files. Visual Studio may have locked some of them, so you may have to close it first.
Download the zipped up Reference Source file for the .NET Framework version you're working with.
.NET v4.5.1
.NET v4.5.2
.NET v4.6
Here's the tricky part. The zip file you downloaded contains a folder called Source. The symbol files will expect that folder to be F:\dd. You can open up one of the PDBs retrieved from the new symbol server you added to see what I mean:
If you have an F:\ drive, it's easy: extract the Source folder from the zip file to F:\ and rename it to dd and you're good to go.
If you don't have an F:\ drive, you create an F:\ partition or load a virtual disk. I used a mapped network drive by extracting the Source folder into the shared folder C:\Code.
Then I mapped a network drive to \\MYPC\Code:
I didn't want to rename the folder to dd, so I named it ReferenceSource and created a directory junction using Command Prompt (must run as Administrator):
cd C:\Code
mklink /j dd C:\Code\ReferenceSource
Voila. Now I have an F:\ drive mapped to C:\Code and a junction dd that points to C:\Code\ReferenceSource.

Remote Debugging visual studio 2010: Breakpoints do not load

I'm trying to remote debug my webpart. I can successfully attach to the remote process but my breakpoints do not load. Can anyone help me?
PS I've checked the "modules" but my assembly is not loaded there.
PPS My .dll is GAC deployed and I am the admin of both the dev and server.
PPS The .pdb files are on the bin folder of the application: inetpub/.../9090/bin
I was wondering if I can force the "modules" to load a given .dll. Is it?
Is debugging enabled in the web.config of the target web application?
http://msdn.microsoft.com/en-us/library/e8z01xdh%28v=vs.80%29.aspx
UPDATE
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
The section on PDB loading says:
The first place searched is the directory where the binary was loaded.
If the PDB file is not there, the
second place the debugger looks is the
hard coded build directory embedded in
the Debug Directories in the PE
file.If the PDB file is not in the
first two locations, and a Symbol
Server is set up for the on the
machine, the debugger looks in the
Symbol Server cache directory.
Finally, if the debugger does not find
the PDB file in the Symbol Server
cache directory, it looks in the
Symbol Server itself.
You need to move the PDB into the same folder in the GAC, or into the same path that you built the assembly from.
Use this method to enable viewing the GAC folders
http://blogs.msdn.com/b/johnwpowell/archive/2009/01/14/how-to-copy-an-assembly-from-the-gac.aspx

Index sources files into a standalone source server without TFS 2010

I have a solution, which is built using Visual Studio 2010 from a command line. After build, a symstore from Debugging Tools for Windows is invoked to post PDBs and binaries to the network folder, which is then used as a symbol store.
I understand there also is a Source Server, which I could use together with Symbol Store to keep the source files. How do I have the source files added to that symbol store? I see there is a srcsrv directory in Debugging Tools, but I cannot find a way to create a source server system outside existing source control system using those tools
Typically you do not add the source files to the symbol store, instead you reference them in your source control systemm, and use Windows Source Server to pull them down as needed (just like it does with the symbols).
You must run a script on the source files to add info to the pdbs, this info contains which version of the files were used and is than used later when you debug to get them.

TFS and local folder permission problem

Environment: VS 2010, Windows 7, TFS
I have a solution1 with solution filder called Binaries(which is a physical path on local
computer, say it's c:\Binaries): I put all external assesmblies in this folder.
In another solution2, for each class library project in this solution, set property->build->Output path to c:\Binaries, so that the latest version of these assemblies can be referenced by any project in solution1
It's working fine.
Now I put solution1 and solution2 to TFS and all of them are under TFS source control, include Binaries folder.
Now I open solution 2 again and build the solution2, it give me permission error for each class library project like:
Error 49 Unable to copy file "obj\Debug\mycomponent.dll" to "....\Binaries\mycomponent.dll". Access to the path '....\Binaries\mycomponent.dll' is denied.
But if I check the permission in windows 7 on c:\Binaries, no problem.
So it should be something wrong with VS 2010 or TFS.
How to fix this problem?
Though I'm not a big advocate of binaries in your source control, there's a workaround for this.
When you get your source, you will need to specifically check out the binaries (to enable write access).
HOWEVER! If you have multiple developers working, this will (by default) put an exclusive lock on the binary files. And they will not be able to check out the files for edit.
The solution for this is in Visual Studio 2010. Go to
Team->Team Project Collection Settings->Source Control File Types and find "Executable Files" on the list. Change File Merging to Enabled and you'll be able to have shared locks on the file.
The other option is to either not "get" your binaries folder, or, if you do get it, "unget" it using
tf get "$/blah/project/Binaries" /server:servername /version:C1 /overwrite /force
You'll need to supply the itempsec and servername. This will get the first version of the binaries, which doesn't exist, so it will wind up deleting them locally and marking them as not gotten (or checked out).

Resources