Debugging symbols not loading in .NET standard project targeting .NET Framework
Asked Answered
H

2

19

I am using Visual Studio 2017. I created a .NET Standard library (let this library be Lib1) project with two Target frameworks, netstandard2.0 and net46. Then I have another two projects... one is a "pure" .NET Framework 4.6 console project (lets call it Console46) and a .NET Core console project (lets call it ConsoleCore). Both of them reference Lib1.

When I run the ConsoleCore project, I can debug and put breakpoints without any problem, but when I run Console46, Visual Studio can not load the pdb file, so I can't debug the library, put breakpoints, etc.

I try to load the PDB file manually because it is created for the net46, but it fails also.

What can I do to fix this problem?

Thank you!

Hopple answered 16/7, 2018 at 14:41 Comment(4)
Try Tools -> Options -> Debugging -> General -> Use Managed Compatibility ModeLatimore
Microsoft has been tinkering with the PDB format, making it a better fit for tooling that runs on the Unixes. That can be an issue when the debug engine you use does not yet understand that new format. Steve's comment would be a good example, that forces an old engine to be used and it definitely doesn't know anything about the new format. Project > Properties > Build tab > Advanced button. Change the "Debugging information" combobox from Portable to Full.Dalmatian
I have had success with the suggestion by @HansPassantFrisch
i have same problem when create symbole with teamcity and index in teamcity symbol server generated file-signs not compatible with load symbol info in debug time in debug time file address like this Sign+ffffffff\file.pdb with @HansPassant solution solved! thanks againShingle
K
4

Here's a successful workaround for something very much similar to what you describe. When my 'Solution' contained only .NET Standard projects and I attempted to Debug using an external 4.6.1 Framework executable (let's call it "Foo.exe" from a separate solution) my breakpoints weren't hitting either.

My understanding is that there are two distinct debuggers, the .NET Core Debugger and the Full Framework Debugger. My vs 'Solution' defaulted to the former since that's the only type of Project that was in it.

What eventually worked for me was tricking VS2019 into using the Full Framework Debugger.

To do this, I added a placeholder 4.6.1 Framework console project to the solution and set it as the Startup project. In the Debug tab I set the Start Action exactly the same, pointing the value in Start External Program to the same one as before ("Foo.exe"). Now the breakpoints work.

NOTES for clarity:

  • The placeholder app doesn't do ANYTHING and is never ever actually run.
  • It doesn't need to reference the other .NET Standard assemblies that you're trying to debug.
  • The "Foo.exe" is the debugging process that gets attached in any case, but the breakpoints are only going to get hit when the Startup Project is a Framework project and NOT when the Startup Project is set to one of the .NET Standard projects in the same solution.

BTW setting the "Build\Advanced\Debugging information" to 'Full' as described in the earlier posts made no difference in my scenario but THANK YOU it made sense and was sure worth a try!

Krusche answered 4/4, 2020 at 19:2 Comment(3)
I got fooled again and this time it was forehead-slap obvious: The Framework.exe client always loads the .dll from its executing directory (barring an explicit Assembly.LoadFrom) but the DLL usually doesn't get there without rebuilding the Framework.exe project (in addition to rebuilding the DLL project) which copies the referenced DLLs. So, rebuilding "only" the DLL project disconnects the breakpoints. The Framework.exe will be loading a stale copy until it's rebuilt. Easy to overlook this if the Framework.exe is in a separate solution because it's automatic when they're part of the same!Krusche
Another good trick: Open up the .cs file from the DLL solution in your Framework solution and run. You can set working breakpoints in that .cs file even though it's not part of the solution. Pure magic if you ask me...Krusche
More good news. Recently, building WinForms project against .NET Core 3.1 and .NET Standard 2.0 respectively in Visual Studio 2019 16.11.3 there no longer seems to be a need for the gyrations laid out in my original answer. (The OP was specifically Framework 4.6)Krusche
P
13

The answer @hans-passant posted in the comments is a good solution.

I rebuilt my .NET-Core libraries with this option in the csproj file. The following is a snippet that gets added to the csproj when you modify the file as per @hans-passant's instructions (Project > Properties > Build tab > Advanced button. Change the "Debugging information" combobox from Portable to Full):

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <DebugType>full</DebugType>
    <DebugSymbols>true</DebugSymbols>
  </PropertyGroup>

I then dumped the built dll and pdb into the bin directory of my .NET-Framework application and I was able to step into my .NET-Core code.

Popular answered 6/6, 2019 at 17:29 Comment(0)
K
4

Here's a successful workaround for something very much similar to what you describe. When my 'Solution' contained only .NET Standard projects and I attempted to Debug using an external 4.6.1 Framework executable (let's call it "Foo.exe" from a separate solution) my breakpoints weren't hitting either.

My understanding is that there are two distinct debuggers, the .NET Core Debugger and the Full Framework Debugger. My vs 'Solution' defaulted to the former since that's the only type of Project that was in it.

What eventually worked for me was tricking VS2019 into using the Full Framework Debugger.

To do this, I added a placeholder 4.6.1 Framework console project to the solution and set it as the Startup project. In the Debug tab I set the Start Action exactly the same, pointing the value in Start External Program to the same one as before ("Foo.exe"). Now the breakpoints work.

NOTES for clarity:

  • The placeholder app doesn't do ANYTHING and is never ever actually run.
  • It doesn't need to reference the other .NET Standard assemblies that you're trying to debug.
  • The "Foo.exe" is the debugging process that gets attached in any case, but the breakpoints are only going to get hit when the Startup Project is a Framework project and NOT when the Startup Project is set to one of the .NET Standard projects in the same solution.

BTW setting the "Build\Advanced\Debugging information" to 'Full' as described in the earlier posts made no difference in my scenario but THANK YOU it made sense and was sure worth a try!

Krusche answered 4/4, 2020 at 19:2 Comment(3)
I got fooled again and this time it was forehead-slap obvious: The Framework.exe client always loads the .dll from its executing directory (barring an explicit Assembly.LoadFrom) but the DLL usually doesn't get there without rebuilding the Framework.exe project (in addition to rebuilding the DLL project) which copies the referenced DLLs. So, rebuilding "only" the DLL project disconnects the breakpoints. The Framework.exe will be loading a stale copy until it's rebuilt. Easy to overlook this if the Framework.exe is in a separate solution because it's automatic when they're part of the same!Krusche
Another good trick: Open up the .cs file from the DLL solution in your Framework solution and run. You can set working breakpoints in that .cs file even though it's not part of the solution. Pure magic if you ask me...Krusche
More good news. Recently, building WinForms project against .NET Core 3.1 and .NET Standard 2.0 respectively in Visual Studio 2019 16.11.3 there no longer seems to be a need for the gyrations laid out in my original answer. (The OP was specifically Framework 4.6)Krusche

© 2022 - 2024 — McMap. All rights reserved.