170

I have two solutions in my workspace, say A and B.

Solution A is an older project which I finished coding some time ago. In solution B, I need to use some classes from Solution A. To do so, I add a reference to the dll of one of the projects in solution A.

The problem is when I try to debug. I want to be able to step into A's code as well. Visual studio is not able to load the code for these classes ("There is no source code available for the current location.") and I can only view the disassembly, which is not useful.

The only way I know to debug classes from solution A is by running solution B, detach all processes (in the Debug menu item) and attach the process from solution A.

However, this is very inconvenient and I can only debug A OR B at once.

Is there a way to allow stepping into the code of referenced dlls (for which I do have the source code)?

Solution: My mistake was that I thought that a project can only be part of a single solution. In fact, a project can be part of any number of solutions.
When you need to reference the old project, you should simply add the project to the solution. This is done by right clicking the new solution in the Solution Explorer > Add > Existing Project.
Then, you'll be able to add the project reference. As others wrote, you should probably completely avoid using dll references to your own code (or other code you might need to change and debug).

A very good reference to how solutions should be designed can be found in MSDN.

Elad
  • 19,079
  • 18
  • 62
  • 71
  • 1
    That MSDN link is a must-read for .net devs (regardless of the source control they use). I'm surprised I hadn't seen it earlier. Thanks! – Pat Jul 23 '12 at 21:16
  • New comers, if you already know about project references, and that's not an option (e.g. you need to debug a NuGet package), then ignore the accepted answer and go straight to this one: https://stackoverflow.com/a/26029208/398630 – BrainSlugs83 Sep 06 '18 at 21:42

12 Answers12

132

If you have a project reference, it should work immediately.

If it is a file (dll) reference, you need the debugging symbols (the "pdb" file) to be in the same folder as the dll. Check that your projects are generating debug symbols (project properties => Build => Advanced => Output / Debug Info = full); and if you have copied the dll, put the pdb with it.

You can also load symbols directly in the IDE if you don't want to copy any files, but it is more work.

The easiest option is to use project references!

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • 3
    Unfurtunately, I think it is not possible to add project reference to project from another solution (correct me if I am wrong!). – Elad Jul 15 '09 at 09:47
  • Yes, you can. I use all the tiem when only one part of a library is used in a new solution. – Wilhelm Jul 15 '09 at 10:15
  • Could you please explain how? When I click "add reference", the Projects tab it only shows projects from the same solution. – Elad Jul 15 '09 at 10:50
  • Thanks Marc! Although I am still unable to add a "project reference" to another solution, now I am able to debug the referenced solution :) The key to solving the issue, as you mentioned, is adding the dll from the original project. My mistake was adding the dll from A's application folder. The dll is copied to that folder when the assembly is compiled. However, the pdb file is not copied and therefore I was not able to debug. – Elad Jul 15 '09 at 11:03
  • 7
    @Elad I just did this. First add "existing project" to the solution. Then add a reference to the project by clicking add project reference. You can set the breakpoints in the existing project files. This is nice because the files aren't copied over. – user420667 Sep 07 '11 at 18:45
  • 3
    I have DLL project as a project reference but break point within are ignored. – Slaus Aug 23 '14 at 10:56
  • 1
    I actually was able to debug a (release-)assembly today that was added as a file reference. Good for me, but how did that happen? MSVC2010, C#, (ASP).NET 4.0, referenced assembly exists as debug+release (but only release-file added to project). Would really like to clarify this. – Tobias81 Dec 12 '14 at 12:40
  • Not sure if I'm just being slow today. I added the reference to the project Solution -> Add -> Existing Project. But can't find the "Add Project Reference" anywhere. However adding a reference to the debug .dll once the other project was part of the solution allowed me to step into the code. – Morvael Nov 10 '16 at 09:12
  • 2
    For me it was working one day but then the next day wasn't working (having DLLs and PDB files). Pressing the "Empty Symbol Cache" button on Tools > Options > Debugging > Symbols fixed it though. – Paul Feb 15 '17 at 12:29
  • Worked for me, but only after I restart IIS service. – Souza Jun 26 '19 at 18:45
  • 1
    How do you load symbols directly in the IDE? – testing May 04 '20 at 10:09
  • 1
    @testing with a symbol server https://learn.microsoft.com/en-us/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2019 – jspinella Mar 23 '21 at 01:56
55

I had the same issue. He is what I found:

1) make sure all projects are using the same Framework (this is crucial!)

2) in Tools/Options>Debugging>General make sure "Enable Just My Code (Managed Only) is NOT ticked

3) in Tools/Options>Debugging>Symbols clear any cached symbols, untick and delete all folder locations under the "Symbols file (.pdb) locations" listbox except the default "Microsoft Symbol Servers" but still untick it too. Also delete any static paths in the "Cache symbols in this directory" textbox. Click the "Empty Symbols Cache" button. Finally make sure the "Only specified modules" radio button is ticked.

4) in the Build/Configuration Manager menu for all projects make sure the configuration is in Debug mode.

scott_f
  • 838
  • 8
  • 17
32

Step 1: Go to Tools-->Option-->Debugging

Step 2: Uncheck Enable Just My Code

Step 3: Uncheck Require source file exactly match with original Version

Step 4: Uncheck Step over Properties and Operators

Step 5: Go to Project properties-->Debug

Step 6: Check Enable native code debugging

Roald
  • 2,459
  • 16
  • 43
Arindam Dhar
  • 321
  • 3
  • 2
15

Another point to keep in mind, be sure the referenced dlls are not installed in the GAC. After testing, I installed my dlls into the GAC to do system level testing. Later, when I had to debug my code again, I couldn't step into the referenced assemblies until I deleted them from the GAC.

KevinHou
  • 151
  • 1
  • 2
  • 2
    THANK YOU! This was my issue. I can't believe I didn't figure this out :-/ I thought setting the project reference would somehow override what was installed in the GAC. – SnookerC Aug 27 '15 at 14:41
  • Absolutely! This is a VERY good point. Even if you have the same version of .NET Framework, if you have code in the GAC when you try to debug it won't hit the breakpoint if the .PDB file in the GAC is different then the one in your project folder. A solution for this is to Un-GAC the DLL, build, then re-GAC the assembly. – DigiOz Multimedia Jul 21 '17 at 23:44
6

I had the *.pdb files in the same folder and used the options from Arindam, but it still didn't work. Turns out I needed to enable Enable native code debugging which can be found under Project properties > Debug.

Roald
  • 2,459
  • 16
  • 43
3

When you want to set a breakpoint in source code of a referenced dll, first make sure that you have a pdb file available for it. Then you can just open the related source code file and set a breakpoint over there. The source file does not need to be part of your solution. As explained in How can I set a breakpoint in referenced code in Visual Studio?

You can review your breakpoints through the breakpoints window, available via Debug -> Windows -> Breakpoints.

This approach has the benefit that you are not required to add an existing project to your solution just for debugging purposes as leaving it out has saved me a lot of build time. Evidently, building a solution with only one project in it is much faster than building a solution with lots of them.

Community
  • 1
  • 1
Carl in 't Veld
  • 1,363
  • 2
  • 14
  • 29
  • 2
    This only works if the external file where you placed the breakpoint matches the exact path in the PDB. (E.g. only works if you built the DLL on your machine.) – Josh M. Nov 29 '17 at 19:20
3

Make sure your DLL is not registered in the GAC. Visual Studio will use the version in the GAC and it will probably have no debugging information.

Guillermo Prandi
  • 1,537
  • 1
  • 16
  • 31
1

I don't want to include an external class library project in some of my solutions, so I step into assemblies that I consume in a different way.

My solutions have a "Common Assemblies" directory that contains my own DLLs from other projects. The DLLs that I reference also have their accompanying PDB files for debugging.

In order to debug and set breakpoints, I set a breakpoint in the consuming application's source where I'm calling a method or constructor from the assembly and then step INTO (F11) the method/constructor call.

The debugger will load the assembly's source file in VS and new breakpoints inside of the assembly can be set at that point.

It's not straight forward but works if you don't want to include a new project reference and simply want to reference a shared assembly instead.

Jeff LaFay
  • 12,882
  • 13
  • 71
  • 101
1

The most straigh forward way I found using VisualStudio 2019 to debug an external library to which you are referencing in NuGet, is by taking the following steps:

  1. Tools > Options > Debugging > General > Untick 'Enable Just My Code'

  2. Go to Assembly Explorer > Open from NuGet Packages Cache List item

  3. Type the NuGet package name you want to debug in the search field & click 'OK' enter image description here

  4. From the Assembly Explorer, right-click on the assembly imported and select 'Generate Pdb' enter image description here

  5. Select a custom path where you want to save the .PDB file and the framework you want this to be generated for

    enter image description here

  6. Copy the .PDB file from the folder generated to your Debug folder and you can now set breakpoints on this assembly's library code

magicode118
  • 1,444
  • 2
  • 17
  • 26
1

The following solution worked for me. It involves copy pasting the .dll and .pdb files properly from project A to B: https://stackoverflow.com/a/16546777/5351410

YoniWitz
  • 119
  • 10
0

It must work. I used to debug a .exe file and a dll at the same time ! What I suggest is 1) Include the path of the dll in your B project, 2) Then compile in debug your A project 3) Control that the path points on the A dll and de pdb file.... 4)After that you start in debug the B project and if all is ok, you will be able to debug in both projects !

Matthieu
  • 2,743
  • 19
  • 21
0

Visual Studio 2022 added a new top-level node: External Sources to solution explorer, which you will find while in debug mode. You can look at all the loaded dlls from there. You can also look at the loaded modules from Debug -> Windows -> Modules in debug mode. From there, right click on your desired dll, and click open file location, and then copy the pdb file to that location. This should allow you to step into any methods of the external dll from the same visual studio window.

Reference: https://devblogs.microsoft.com/visualstudio/debugging-external-sources-with-visual-studio/

Rayhan
  • 16
  • 3