dotnet/core

Assembly built with "Portable" debugging information - contains source information

Closed this issue · 1 comments

pavlexander commented

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

  • none

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

2.2.104

Prerequisites

Checkout the solution from my repo:

https://github.com/pavlexander/dotnetbugs/tree/master/Bugs/13032019_DllIncludesPdbInformation

Steps to reproduce

  1. Open the solution in VisualStudio
  2. 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".
  3. 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"
  4. Go to "Program.cs" of console application and un-comment the line which is marked with a comment.
  5. Put a debug point onto the same line that you have uncommented.
  6. 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:

  1. 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.

  2. 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.

leecow commented

Issue moved to dotnet/cli #10982 via ZenHub