I have a .net 4.0 web project which is running in debug mode. This was running perfectly until recently. Now it errors saying it can't fine various PDB files. The PDB files it is looking for are all present. However looking at the trace .NET is trying to find them with either a .pdb.exe or .pdb.dll extension.
Why is it looking for the extra part of the extension rather than just .pdb?
No application, web or otherwise will ever complain about finding PDB files.
I suspect you accidentally changed your assembly names instead of the debug output filename.
Related
We are developing a small framework within the company and there is a small weird issue with pdb files.
While developing framework, we also commit pdb&dll outputs and related projects are referenced directly to these dlls.
But when i build and commit these dlls, my companions cannot navigate to sources of framework. When someone else builds, i cannot navigate to source.
Only thing i can do is to use resharper's navigation via "navigate to -> decompiled sources".
There is something wrong i think. They are the same files so that i should be able to navigate to their files directly.
Btw, we do not version framework. All dlls use same 1.0 version.
Anyone having an idea?
I found the answer. Using DUMPBIN I examined all pdb files and there were full paths of last build, which is different in my computer.
For ex: my collegue build framework project in d:\projects path however, working directory in my computer was c:\projects so that pdb files somehow not found (which is veird. The paths should be relative imo)
When one of us changed framework project path and if we both use the same path; no matter who built that project last, it just worked. I can navigate source codes directly in Visual Studio.
It can be that you need to disable Optimize Code on release build to make it work. Try that..
I have a web application developed at d:\projects\webapplication1 and it is published at d:\websites\webapplication1. I am browsing the website in IIS and attaching the process in visual studio, and it works. So, how does the debugger work in this case despite the source code and published code are in different locations.
The PDB files contain the absolute paths of the source files used to build the binaries. The sources will be automatically found if the absolute paths are valid.
The published code probably has a PDB file which has the file path for your code. The code will contain some debugging information (used for stack traces for instance) even without the PDB file being generated.
What is the best/correct way of attaching an external project source code so I can debug it?
I´ve already downloaded the source code of it from CodePlex, so I have all the .cs classes.
I´ve managed to import from a pdb file, but unfortunately, there´s no such file in this project codeplex (SimpleInjector).
After importing the SimpleInjector solution on VS, I could build it and generate the .pdb files, but I wonder whether it is the right way.
If your goal is to step-through debug the binary, then you will need the PDB files. In general, the compiled assembly just doesn't contain the information needed to associate source-code lines with individual IL commands.
The PDB file is a "program database file" which contains lots of useful debugging information; one of those things is the mappings between each compiled IL instruction and the source-code line that generate it. It also keeps a symbol table that lists the names of things that otherwise get compiled out (like local variable names, etc.) The PDB embeds the full path name of each source file, so if your source code is in the same place when you debug as it was when you compiled, the debugger will automatically find it.
If the .pdb file is present but the source code has moved, VS will give you the option to browse to the .cs file. But, if the .pdb file isn't present at all, your options will be rather limited.
The only risk you have is that you are debugging a program that doesn't match your PDB files. Therefore, if you are doing to try to debug the project, you should rebuild, from scratch, in Visual Studio and run that version of the binary.
(Debugging without symbols and source loaded into Studio is, of course, possible, but it's a much harder skill to master.)
Is the .pdb file enough to debug and step into the code of a dll? Or do you actually have to reference the corresponding project source code?
I tried referencing a dll with the .pdb file in the same directory, and was unable to step into the code of the dll. So I was wondering what the rules around dlls and .pdb files where.
Thanks in advance.
The .pdb file will allow you to debug, but it will not provide any sources. Check out this blog post for an excellent description of PDB files and their purpose.
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
The PDB file is how visual studio knows how the executing code in the assembly corresponds to the lines in the source code. The answer to your question is yes, Visual studio needs the source code that the corresponding pdb was built from.
The pdb does not contain the source code packaged inside of it (well it can, but it is a bit of a hack and not many people do it), however the symbol server should automatically download it if it has the source available. However the pdb must match the exact version as the dll you are working with for it to download the source.
I have a small suspicion that you are trying to do the .NET framework source stepping and it is not stepping in to it. Microsoft has not updated the symbol servers with the current versions of the pdb files so source stepping is broken if you are running a up to date version of .net (at least until they release the new versions of the source files).
What is a PDB file and how can I exclude it from the release folder when I rebuild my solution?
A PDB file contains information for the debugger to work with. There's less information in a Release build than in a Debug build anyway. But if you want it to not be generated at all, go to your project's Build properties, select the Release configuration, click on "Advanced..." and under "Debug Info" pick "None".
I had originally asked myself the question "Do I need a PDB file deployed to my customer's machine?", and after reading this post, decided to exclude the file.
Everything worked fine, until today, when I was trying to figure out why a message box containing an Exception.StackTrace was missing the file and line number information - necessary for troubleshooting the exception. I re-read this post and found the key nugget of information: that although the PDB is not necessary for the app to run, it is necessary for the file and line numbers to be present in the StackTrace string. I included the PDB file in the executable folder and now all is fine.
PDB is an abbreviation for Program-Debug Data Base. As the name suggests, it is a repository (persistent storage such as databases) to maintain information required to run your program in debug mode. It contains several vital information required for code debugging e.g. at what points you have put break points where you expect the debugger to break in Visual Studio (VS).
This is the reason why Visual Studio fails to hit the break points if you remove PDB files from the debug directory. Visual Studio debugger is capable of telling you the exact line number of code file at which any exception occurred along with its stacktrace. It is able to do so with the help of PDB files only. Thus PDB files are very helpful for debugging purposes.
In general, it is not recommended to exclude the generation of PDB files during build process. From production release stand-point, what you should be doing is create the PDB files but don't ship them to customer site in product installer. Preserve all the generated PDB files on a symbol server from where it can be used/referenced in future if required.
It is specially important in scenario where you debug process crash issues. While analysing the crash dump files, Visual Studio will not be able to make out the exact line of code where program is crashing if the original PDB files created during the build process were not preserved.
If you still want to disable generation of PDB files then follow below steps:
Go to properties window of the project. To open properties window, select the project file in solution explorer and press Alt + Enter.
Go to Build tab
Click Advanced
Choose none from Debug Info drop-down box
Press OK as shown in the snapshot below:
Note: This setting will have to be done separately for Debug and Release build configurations.
A PDB file contains information used by the debugger. It is not required to run your application and it does not need to be included in your released version.
You can disable pdb files from being created in Visual Studio. If you are building from the command line or a script then omit the /Debug switch.
Program Debug Database file (pdb) is a file format by Microsoft for storing debugging information.
When you build a project using Visual Studio or command prompt the compiler creates these symbol files.
Check Microsoft Docs