search

dotnet / roslyn

The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
https://docs.microsoft.com/dotnet/csharp/roslyn-sdk/
MIT License
19.12k stars 4.04k forks source link

vbproj honours PdbFile setting, but the executable still expects AssemblyName.pdb #14487

Open markhurd opened 8 years ago

markhurd commented 8 years ago

Version Used: Visual Studio 2015 Version 14.0.25431.01 Update 3

Steps to Reproduce:

  1. Edit a.vbproj to specify <PdbFile>SomeName.SomeThing.pdb</PdbFile>
  2. Compile and note SomeName.SomeThing.pdb is generated.
  3. Debug and note no symbols can* be loaded.
  4. Check the strings in the compiled assembly for ".pdb" and note that the one you find is "AssemblyName.pdb"

Expected Behavior: The compiled assembly should reference "SomeName.SomeThing.pdb", and be debuggable. The C# compiler works in the same scenario.

Actual Behavior: The compiled assembly is still associated with a non-existant "AssemblyName.pdb".

Mitigation: I know the PdbFile property (as described here) is actually for "the product infrastructure", and the command line compiler does not document (or seem to support) a /pdb option (like C# does). But seeing as the <PdbFile> setting is honoured, it should be useful.

*It would be nice if there was a way to override this too, but I assume it is too hard to determine when it really is the right (or close enough) file for the build specified.

gafter commented 7 years ago

@tmat Do you know anything about this?

tmat commented 7 years ago

@gafter First of all, VBC doesn't have this command line switch. 

/pdb:<file>            Specify debug information file name (default: 
                       output file name with .pdb extension)

Maybe we added it to the task, but it might not be passed around everywhere where it needs to be ...

tmat commented 7 years ago

if we decide to bring VB on par with C# I'd start by tracing the flow of the option in C# and do the same for VB.

markhurd commented 7 years ago

BTW C#'s support for this isn't great either. I have a DotLisp.dll and I want a DotLisp.exe, and both debuggable. It still seems like the best option is to compile a DotLispREPL.exe and manually rename it, because more things work with it that way.

gafter commented 6 years ago

Placing in the 16.0 milestone. If this is still really a bug, we should really fix it.