Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
pavlexander opened this issue Mar 14, 2019 · 1 comment

Comments

@pavlexander
Copy link

pavlexander commented Mar 14, 2019

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 leecow closed this as completed Mar 15, 2019
@leecow
Copy link
Member

leecow commented Mar 15, 2019

Issue moved to dotnet/cli #10982 via ZenHub

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants