You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assembly built with "Portable" debugging information - contains source information
Description
When referencing an assembly that was build with "Portable" debugging information - it is possible to step into the source code, while in debug mode. According to documentation - "Portable" debugging information ensures that a "pdb" file is created. It says nothing about the fact that the DLL itself will contain an information about where the DLL was compiled at. Therefore, when this information is inside DLL - you are able to step into the source, given that location and checksum not changed.
Specifies that no debugging information will be generated.
portable
Produces a .PDB file, a non-platform-specific, portable symbol file that provides other tools, especially debuggers, information about what is in the main executable file and how it was produced. See Portable PDB for more information.
General
Specs
OS:
OS Name Microsoft Windows 10 Enterprise
Version 10.0.16299 Build 16299
VS:
Microsoft Visual Studio Professional 2017
Version 15.9.7
VisualStudio.15.Release/15.9.7+28307.423
Microsoft .NET Framework
Version 4.7.02556
dotnet --version
Build project "DllWithPortableDebuggingInformation" Note 1: see the post-build events. The script will copy the DLL into a console app project. Note 2: script will also delete PDB so there is no information anywhere about the source.. Note 3: see the project settings. Debugging information set to "Portable".
For console application, right click on project, "Add -> Reference". Browse for DLL that was copied into the root folder of console app project, add a reference to it!
Path: "\Bugs\13032019_DllIncludesPdbInformation\DllIncludesPdbInformation\DllWithPortableDebuggingInformation.dll"
Go to "Program.cs" of console application and un-comment the line which is marked with a comment.
Put a debug point onto the same line that you have uncommented.
Start console app in debug mode. On break - step into the code of external library.
Expected result:
Stepping into the code is skipped because DLL has no information about source code location.
Actual result:
Stepping into the code works, despite the fact that PDB file does not even exists.
Proposed solution
We either need information about this behavior to be properly documented, or, if it's a bug, then it needs to be fixed.
Additional questions
Please take a minute to answer following questions:
How to tell, if PDB information is embedded into an DLL? For example, can I use "JetBrains dotPeek" to inspect DLL and see what kind of information it contains about the source? I couldn't find any tutorials on how to do it and how/where this information is stored in DLL. Any hints or links are appreciated.
Is it possible to override the "default source location" for the loaded DLLs? For example, if an assembly was compiled at "C:/myCompiledLibs", but afterwards I moved the source to "D:/newLocation" - how do I make it so, that the Visual Studio would look into this new directory for sources, instead of using this info that is embedded into DLL/PDB?
Any answers are much appreciated.
The text was updated successfully, but these errors were encountered:
Assembly built with "Portable" debugging information - contains source information
Description
When referencing an assembly that was build with "Portable" debugging information - it is possible to step into the source code, while in debug mode. According to documentation - "Portable" debugging information ensures that a "pdb" file is created. It says nothing about the fact that the DLL itself will contain an information about where the DLL was compiled at. Therefore, when this information is inside DLL - you are able to step into the source, given that location and checksum not changed.
Here is the documentation I was referencing to:
https://docs.microsoft.com/en-us/visualstudio/ide/reference/advanced-build-settings-dialog-box-csharp?view=vs-2017
General
Specs
OS:
OS Name Microsoft Windows 10 Enterprise
Version 10.0.16299 Build 16299
VS:
Microsoft Visual Studio Professional 2017
Version 15.9.7
VisualStudio.15.Release/15.9.7+28307.423
Microsoft .NET Framework
Version 4.7.02556
dotnet --version
2.2.104
Prerequisites
Checkout the solution from my repo:
https://github.com/pavlexander/dotnetbugs/tree/master/Bugs/13032019_DllIncludesPdbInformation
Steps to reproduce
Note 1: see the post-build events. The script will copy the DLL into a console app project.
Note 2: script will also delete PDB so there is no information anywhere about the source..
Note 3: see the project settings. Debugging information set to "Portable".
Path: "\Bugs\13032019_DllIncludesPdbInformation\DllIncludesPdbInformation\DllWithPortableDebuggingInformation.dll"
Expected result:
Stepping into the code is skipped because DLL has no information about source code location.
Actual result:
Stepping into the code works, despite the fact that PDB file does not even exists.
Proposed solution
We either need information about this behavior to be properly documented, or, if it's a bug, then it needs to be fixed.
Additional questions
Please take a minute to answer following questions:
How to tell, if PDB information is embedded into an DLL? For example, can I use "JetBrains dotPeek" to inspect DLL and see what kind of information it contains about the source? I couldn't find any tutorials on how to do it and how/where this information is stored in DLL. Any hints or links are appreciated.
Is it possible to override the "default source location" for the loaded DLLs? For example, if an assembly was compiled at "C:/myCompiledLibs", but afterwards I moved the source to "D:/newLocation" - how do I make it so, that the Visual Studio would look into this new directory for sources, instead of using this info that is embedded into DLL/PDB?
Any answers are much appreciated.
The text was updated successfully, but these errors were encountered: