0

I have a .NET solution X that targets .NET framework net7.0. In X I reference (import) a self-created NuGet package that uses dlls from another solution - Y that targets multiple .NET frameworks: net472 and netstandard2.0.

My main issue is that when I debug X I cannot set breakpoints on the assemblies coming from Y.

When I open the processes window in Visual Studio (Debug -> Windows -> Processes) in X, I see a debugger for the following version of .NET: Managed (.NET Core, .NET 5+). When I open the same window when debugging Y, the debugger is configured to debug Managed (.NET 4.x). This Microsoft guide explains that this might be the root cause of my problem. However, I don't know how to add / change the debugger version used in X and also worry that if I change it to match Y's version I will no longer be able to debug code in X.

Things that I've tried so far, which did not work:

  1. Manually copied over relevant .pdb files to the Debug folder of X
  2. Added a symbol file location in settings - it contains the dlls and pdb files that are used to create the NuGet package
  3. Turned off "Just my code" option in settings
  4. As suggested here, started X without debugging and attached to it from another VS instance - as my debugger I chose: Managed (.NET Core, .NET 5+) and later Managed (.NET 4.x) but neither setup worked
trubby22
  • 21
  • 3
  • When the debugger is attached (it doesn't matter if you use f5 debug, or attach to process), open the Modules window. In the modules window find the dll that you want to step into and set breakpoints in, and make sure the "symbols loaded" column says yes. If it doesn't, then the debugger hasn't found the correct symbols for the dll, and you need to fix this first, before you're likely to have success with debugging and breakpoints. If you copied pdbs into a path that the debugger searched, it means you didn't copy the correct pdb. the pdb has a hash of the dll its for. – zivkan Aug 24 '23 at 04:22
  • My modules list doesn't even show the dll I'm interested in. On a separate note, certain dlls from Y get loaded properly (show up in the list and their symbols get loaded) while others don't. Both modules are class libraries. The only difference between them is that the correctly loading module targets net472, while the non-loading one targets both net472 and netstandard2.0. – trubby22 Aug 24 '23 at 08:37

0 Answers0