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.
Related
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.
In my company, people used to work with Visual SourceSafe, but some years ago they decided to start working with GIT.
I started working here some months ago, and as such I've never set up a Visual SourceSafe environment.
While debugging dumps from older versions, this is giving problems: it seems that the dumps (taken using procdump) contain commands for retrieving source code, using Visual SourceSafe.
I've just installed Visual SourceSafe, and I was hoping that this would make it possible to get the older versions of the source code, but this is not the case. (For your information, even after having installed Visual SourceSafe, I don't see any SourceSafe information in Visual Studio's "Team Explorer - Connect" window)
(the original question contains quite some investigation information, which seems to be obsolete now that the answer of this question is known)
How things are related
[...] it seems that the dumps (taken using procdump) contain commands for retrieving source code, using Visual SourceSafe.
A crash dump does not contain commands. It contains version information about the EXE and the DLLs that were loaded. WinDbg and Visual Studio will then look for PDB files which match that version information. The PDB file then contains information about the source code.
To find PDBs, you need a symbol server and/or a local path with symbols.
SourceSafe
I've just installed Visual SourceSafe, and I was hoping that this would make it possible to get the older versions of the source code, but this is not the case.
Installing SourceSafe does not help. You'll need to connect to a repository using Visual SourceSafe Admin and grant yourself access rights.
Then, using Visual SourceSafe (not Admin), map a local folder ("Set working folder") and pull ("Get latest version"). You then have the source code locally and you can instruct your tools to use that path. For WinDbg, .srcpath and .lsrcpath should be correct.
You might need to get different versions by date if you really want to analyze with source code. To automate this process, you would need a source server, but you would know if you have one.
The age of the dumps
You say:
[...] some years ago they decided to start working with GIT.
So your source code should be in GIT, not in SourceSafe.
If your crash dump file is so old that it refers to SourceSafe, then consider it as obsolete and take a new dump. If nobody complains about crashes recently, I would no longer care (saying that as a former Test Manager).
Unbelievable: the issue is caused because the SourceSafe installation seems not to be complete:
In order to get it working, the following needs to be done:
Add the SourceSafe directory to the $PATH$ environment variable (C:\Program Files (x86)\Microsoft Visual SourceSafe)
Create the $SSDIR$ environment variable in order for SourceSafe to know where to look for the source code (should refer to the directory, containing the srcsafe.ini file).
I've published some private/internal libraries as NuGet packages, using the symbols option. The packages and symbols are hosted on an internal network share. How can I step into these packages when debugging?
When I step to code from these packages, Visual Studio displays a "No Source Available" / "No Symbols Found" page. Clicking the "Load Symbols" only allows pdb files, not symbol packages.
These packages are not suitable for publishing on NuGet Gallery/SymbolSource.
What is the command that you used to generate the packages with the symbols? I tried to do the same exact thing nuget.exe pack -Prop Configuration=Release Framework.csproj -Symbols This creates two files: Framework.nupkg and Framework.symbols.nupkg. I put these files on a network share, used them from another project and debugging worked fine.
Have you tried putting the *.nupkg and *.symbols.nupkg files on a local disk instead of a network share?
There are a couple options; one is to set-up & configure your own symbol server.
You could also download Inedo's ProGet, enable symbol serving on the target feed, and then publish your packages to ProGet. All of this can be done with the free edition of ProGet.
disclaimer -- my day job is at Inedo
There is also now a tool called GitLink (https://github.com/GitTools/GitLink) which can insert into the symbol file links to versioned GIT files of your source.
You can set up your own symbolsource server internally using those network shares.
You can find a step-by-step tutorial on my blog.
It basically comes down to create an empty MVC application and run
Install-Package SymbolSource.Server.Basic
From there on you need to set up the hosting infrastructure and configure Visual Studio and build agents.
The way we do it (and works):
Generate "*.symbols.nupkg"
Deploy symbol package to SymbolSource server (private)
Configure IDE
Add required Library to project using NuGet (from our SymbolSource server)
Debug!
Links that can be useful:
SymbolSource server installation
Important: "Debugging Tools for Windows" won't install if it detects newer Visual C++ Redist version in the system than it needs/expects
Vs configuration to debug using SymbolSource
The URL to add is like http://your.symbolsource-server.com:[port]/[appContext]/WinDbg/pdb
I found that it doesn't work at all. NuGet package references are closed and cannot be used in the debugger. What I did instead was deleting the assembly reference from the project and instead added a reference to a Debug build of the DLL directly by path.
Then to make the debugger halt somewhere in that code, I inserted the call System.Diagnostics.Debugger.Break(); in that code. When running, the debugger will halt at that line, which is basically a code-defined breakpoint. This will open the correct source file and jump to that line automatically.
Open the library project in a second VS instance and move around the Break calls as necessary and rebuild the library. When done, remove those calls from the library code and restore the original reference (may need to reinstall the NuGet package).
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.
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.