Is it possible to view the source code of a built-in function directly from visual studio 2017?
For example if I want to view the source code of the WriteLine function, I selected it, right clicked it, and when I pressed on Go To Implementation, it gave me this message:
în Call stack you can choose something like "Show External Code", should resolve your problem.
What you need are the .pdb files. Every .dll needs a corresponding .pdb file that maps the .dll to the source code. For your example, System.Console, you need the .pdb file for mscorlib.
The following pages show how to load this pdb file
https://social.msdn.microsoft.com/Forums/SECURITY/en-US/166c70e7-9e39-44bf-8e08-76231e59ec34/mscorlibpdb-not-loaded?forum=visualstudiogeneral
"mscorlib.pdb not loaded" yet the mscorlib.dll is NOT missing
Optionally, if you feel risky enough, you can download the the c# project and try to compile the .pdb file your self
https://referencesource.microsoft.com/download.html
I have embedded the C# source code into a portable PDB file using the <EmbedAllSources> element in the csproj file, and I have embedded the pdb into the assembly using the <DebugType>embedded<DebugType> as described in Embedding C# sources in PDB with new csproj
My assembly looks like this:
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<EmbedAllSources>true</EmbedAllSources>
<DebugSymbols>true</DebugSymbols>
<DebugType>embedded</DebugType>
</PropertyGroup>
I can confirm that the pdb is type portable, and contains my source code:
According to the release notes for Visual Studio 15.5 the debugger should be able to use these files during debugging:
https://learn.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes-v15.5#EmbeddedSource
I'm using Visual Studio 2017 (version number 15.8.8)
However, when I F11 into the code from my assembly it asks for the sourcecode:
Whilst googling around there's a comment from ctaggart in the discussion https://github.com/ctaggart/SourceLink/issues/192 which says running sourcelink print-urls will print "embed" but mine doesn't, perhaps this is a hint:
Has anyone got this to work successfully? If so can you tell what I'm doing wrong?
Easiest way is to go to:
Debug -> Windows -> Modules
Inside this list, you should be able to find your assembly (dll/exe).
Right click it -> Load Symbols
It will ask for where to load the symbols from.
Navigate to the directory where your matching .pdb file is.
It should auto load. Stepping into, or having uncaught errors in this referenced assembly should trigger a break in that code, or ask you to navigate to the code file that corresponds to the file that threw the error.
In our process, we generally have to navigate to the nuget cache to find the pdbs for our installed nuget packages. (%UserProfile%/nuget/packages/YourPackage/VersionNumber/../..)
We also package up the source with those packages and navigate to those /nuget/packages .cs files as well, though, any corresponding .cs file should allow it to load.
I've reviewed the threads I can find on this subject, but none of the proposed solutions seem to help. So I'll ask again!
My Visual Studio 2015 will not step into 3rd party code for which I have the pdb in my bin folder when I run in debug mode. I even see the pdb file downloaded as Visual Studio loads symbols. When I attempt to step into the 3rd party code, Visual Studio complains that it can't find the .cs file. I've tried toggling the 'Enable Just My Code' setting. Visual Studio used to be able to step into 3rd party code; I'm not sure what changed.
I am attempting to step in the context of a unit test, in case that matters. The pdb file is in my unit test bin directory.
My debug settings are below. What am I missing?
Edit: Context menu from right-click on method in call stack
Make sure you have source code to source debug.
Pdb file only contains debug information which is like mapping between executable code and your source code. With pdb VS debugger knows where in source files each instruction is located, but it still needs to have source files to show you the code.
When it cannot find source file VS debugger will show dialog box to browse for the source file. So without source code, VS cannot debug it properly.
Workaround is to use some tools like Resharper, Reflector which could decompile it
My solution uses classes from .dlls generated by my other solutions
.dll where generated in debug mode on the same machine, pdb files are present
steeping into those external sources during debugging works, so I am assuming pdb files are correct
pdp files are in the same directory as .dlls
In R# settings I have "Navigation to Sources" selected and "Use debug information for navigation checked"
VS2012 Pro and R# 8.02 Full
It drives me crazy, how come such crucial thing, that is provided out-of-the-box in every common free IDE for Java, is impossible to get to work in C# using tools for hundreds of bucks...
Looking at the dump in the gist you posted, the first issue I can see is the empty section for PdbCacheManagerImpl. This is the list of pdbs that ReSharper knows about. This shouldn't be empty. There is a known bug that can cause this to be empty. Try closing and reopening the solution to see if that kicks it off again.
Similarly, the assemblies in your PdbServiceImpl section don't include any information about pdbs. I think this is related to the PdbCacheManagerImpl - since ReSharper doesn't know about the pdb files, it doesn't get listed here. When it's working, it should show the pdb file related to the assembly, plus a list of all symbols in the pdb, and the file(s) they map to.
(I can recreate this by creating a new solution - the dump shows nothing in this section. Close and reopen and it shows known dlls, with flags to say if they support source servers and whether they contain a map between symbols (types) and source files. After closing and reopening, I can download and see source for e.g. Console.WriteLine, and the PdbServiceImpl has an entry for System.Console in the mscorlib pdb)
Secondly, you don't have "Allow downloading from remote locations" enabled in your options. This will only affect you for downloading pdb files from symbol servers, it shouldn't stop things working with pdbs next to dlls. You will need it enabled to navigate to source of Console.WriteLine, though.
So, unfortunately, my advice right now is to close and reopen the solution, and try again. You might be hitting the known bug, and the only way to work around this is to close and reopen. Once you've reopened, try navigating again, and try dumping the support information again - you should see more pdbs in the PdbCacheManagerImpl and a list of known symbols in the PdbServiceImpl section.
I want to use debug symbols, but I am receiving the following error:
a matching symbol file was not found in this folder
What is this problem, and how to solve it?
One of the things I've ran into with was because debug was off on the project referenced where the code lives. In my case, I made a new configuration called "Developer" and by default debug was turned off.
Right click the project in question
Properties
Build
Advanced (right bottom corner)
Set Debug Info to full
Recompile
I had the same problem as #DmainEvent. Apparently the dll that I was using was not the same version as the pdb that I had just compiled, so I got the error message.
If you have this problem, try using the dll and pdb from the same compilation run.
The error I got was "a matching symbol file was not found in this folder" in the Debug => Modules window even after both the DLL and PDB were available and built together, so I was unable to debug into the target DLL referenced by my main project.
Posting this here in case it helps someone browsing with "Mixed Platform" build for target DLL. I did two things to get past this:
In the solution using the target DLL, Uncheck "Just My Code" in Tools => Options => Debugging => General => Enable Just My Code (JMC).
Check "Enable native code debugging" in target DLL solution in relevant Project Properties => Debug.
I tried all the possible solutions, finally it worked when I disabled the option Enable native code debugging under the Debugger engines of Properties > Debug.
I ran into this problem and the answer was simple.
Visual studio has two project level settings that can create .pdb files.
Linker: Configuration Properties -> Linker -> Debugging -> Generate
Program Database File = "xxxx.pdb"
Compiler: Configuration Properties -> C/C++ -> Output Files -> Program Database File Name =
"yyyy.pdb"
You want #1 for debugging. Forget about #2.
Give file #2 a different name than file #1 to solve this error.
I don't know why microsoft specifies #2 as a .pdb file. That is just confusing.
I have fixed my debug symbols, forcing them to match using this tool:
chkmatch tool
edit: the website is down now. the wayback machine helps: https://web.archive.org/web/20210205095232/https://www.debuginfo.com/tools/chkmatch.html
So, my problem was I was trying to debug my project and the debugger couldn't step-in to the in-house nugets sources. I had the source files of the nuget project. Still the visual studio didn't accept the pdb files I was trying to show it to.
Showing exact same error:
a matching symbol file was not found in this folder
So, what I did was I added this to the .proj file of the nugets project:
<DebugType>full</DebugType>
And created the dll and pdb file again using the rebuild option.
In the command line I ran:
.\ChkMatch.exe -m name_of_your.dll name_of_your.pdb
It said this:
Writing to the debug information file...
Result: Success.
Great success!
So, next, I referenced this dll instead to the proj I was trying to debug. I worked when I tried to load the symbol again.
Hope it helps.
Without more details as to what you're doing, it's difficult to go beyond "the debugger is looking for a symbol file which matches the compiled code, and couldn't find one in the folder where the compiled code lives."
Some things to think about:
Are you creating symbols as part of your compilation? (check the project properties)
Are you using a symbol server (if so, does it point to the right place)
Is this compiled code from a third party? In which case, as you apparently have the source, compile it yourself.
Consider clarifying your question if you want a better answer. Especially what do you mean by "I want use of Symbols".
For BizTalk (and other) projects, it could be because there's a version of the assembly you're trying to debug already in the GAC. When you run a unit test or hit F5 to debug, a new version is compiled locally. However, the version in the GAC is being used, and the newly created PDB doesn't match the DLL in the GAC.
One way around this is to deselect a build for everything except your unit test project using the Configuration Manager, as shown below:
Well, the solution depends on your specific problem. I tried everything that could be possibly found on Stackoverflow and other sites. One of the thread that I followed is this. That did not help too.
The problem was at once resolved when I noticed that my executable project did not contain a reference to the library that I wanted to debug. So I just added the reference to that project.
**PS: ** This problem might also arise because the assembly referenced by the executable assembly might not match that in the references. So in that case, you just remove the already existing reference and add the new one.
Hope this helps!
The same happen to me because the .pdb file of the project have not been copied to the debug\Bin folder, so the symbols could not be loaded from the .pdb file.
You must rebuild your project and manually copy the symbols (.pdb file) to the debug\Bin folder of executable project.
I was trying to load symbols for a installed nuget package published on our local dev server. I had to uninstall and add a normal reference built from the code instead. This worked for me. Just remember install the original nuget package again once finished debugging.
If it works for you, try to embed debug symbols in the dll itself, so the symbols are loaded automatically. This worked for me in netcoreapp3.1 and net5.0:
<DebugType>Embedded</DebugType>
<EmbedAllSources>True</EmbedAllSources>
Beware that you may find this in documentation:
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
but it does not work.
I ran into this with Visual Studio 2022, tried the most of answers here. Fixed by switching back to Visual Studio 2019, seems like a bug in 2022.
My issue was a bit simpler to resolve, but still the issue the question asked. At first, I was not publishing the pdb file with the nuget package another project was using. Once I confirmed that, I removed the nuget package from my project and readded it from our network nuget source. That still didn't let Visual Studio pick identify the PDB location.
Then I noticed that if you select one of your nuget packages, ( Project --> Dependencies --> Packages --> Choose nuget package), there is a Path property. I checked that location and it pointed to %USERPROFILE%.nuget\packages. The pdb was not at this location and the Date Modified was older than the latest package I published. Once I deleted the folder for the given package version, removed it from my project, and re-added it, the latest .dll and .pdb file were added to this location.
After that, I was able to step into the code of my nuget package and had no further issues.
To get the nuget project to produce the pdb file in the first place, I added <IncludeSymbols>true</IncludeSymbols> inside of a PropertyGroup within the csproj file as other answers had directed.
Once I rebuilt that nuget project, it generated 2 *.nupkg files:
Namespace.x.x.x.x.nupkg
Namespace.x.x.x.x.symbols.nupkg
I found this was because the Properties => Debug => Start Action was set to Start external program instead of the Project. So the newly generated pdb file didn't match, because the actual exe was the wrong one.
I have had this problem recently as well.
Was able to fix it by selecting MyProject->Properties->Linker->Debugging->Generate Debug Info->"Optimize for debugging (/DEBUG)".