I'm trying to debug my code in Visual Studio but my Breakpoint is not hit,it's giving me this message "Breakpoints set but not yet bound"
The breakpoint is in a project that is not set as StartUp Project because it is a library project, my controller calls the method by invocation, I also verified that the dll generated by the solution that contains the library is the same as the project added to my solution
I've read various other questions and tried various solutions like closing VS, deleting bin and obj folders, clean and rebuild but I can't reach those brakpoints
You may have a few options to resolve your issue. First and recommended, your dll and exe project should be in the same solution and both in debug mode. If the projects are in separate solutions, set the breakpoint on the method call on the exe project side. Then pressing F11 should let you into your dll code. If you don't own the project or solution exe, you have the option in VS to link your dll to a running process, but you will only be able to link compiled binaries with managed code. For example, your dll could probably link to windows explorer, but any code will run as far as I know.
I am using Visual Studio 2017 Enterprise and I have an ASP solution which uses several compiled dlls that reference one another sequentially i.e. my solution references A.dll, A.dll uses B.dll and so on. My solution uses .NET 4.0 and the dlls have each been compiled in .NET 3.5. I want to debug the entire stack until a call in the last dll (D.dll). These are the dlls:
What I did: I've unchecked Enable Just My Code and I checked Enable .NET Framework source stepping. I generated the pdb files for each dll using dotpeek and then I moved them in Symbols Cache folder and also specified modules to load these specific dlls.
When I debug (I run the solution in Debug mode with Any CPU configuration) I can see each pdb loaded in the Debug/Windows/Modules window, I can see the source code for each window, and everything works ok until I reach A.dll. When I try to step into B.dll, I get the following message:
Your app has entered a break state, but no code is currently executing
that is supported by the selected debug engine (e.g. only native
runtine code is executing).
What is weird is that if I set Function Breakpoint in the D.dll, that breakpoint is hit, but the same approach does not work with B or C. There is no warning like 'The current breakpoint will not be hit', it just does not trigger. I want to see the entire flow from my solution to the last dll.
Does anybody have any idea why this happens? Do I need to do something else to cascade through the stack call?
Any help is appreciated.
I have been working with multiple projects (3-5, 1 exe, rest dll) in a solution and have not had any problems till now. Now one of my projects (dll) won't debug in the solution. The exe and two dlls are c# and the rest are vb. The vb dlls are the ones that won't work now. We have just changed source control and I dropped and added the projects back together and that is the biggest difference. Since then I am receiving "the breakpoint will not be currently hit. No symbols have been loaded for this document", error. It is not showing in the debug->windows->modules and so far I have added it and dropped it, reset references to all solutions, rebooted and researched all over the internet. Also, I am working with Visual Studio 15.
The dlls have not been loaded to the process which you are trying to debug, under project properties check if optimize code is checked-in this will cause VS to see assembly as "not my code", it will not load symbols for it.
Ok, finally got this to work, thanks to one of my co-workers. I was referencing the dll from the bin folder in my exe. We deleted the reference and created a new reference linking it directly to the debug folder of the dll. I could then step into the dll.
I am developing a C# Console app with Visual Studio 2013 Pro targeting .NET 4.0.
Part of this project includes confidential IP so I have created a DLL which contains that IP and a dummy DLL which I use when I have to hand out the code to other folks. I use a #if to include one or the other. The stub compiles and provides testing capabilities. The DLL Actually started out as just another class of the Console app but I just compile it separately to a DLL now. .NET4.0.
I can set breakpoints either in my Main or my DLL and it works fine. I can step through both etc.
The issue is that if there is an error in the DLL, VS breaks at the call in the main program and not at the error in the DLL with a not-so-helpful error message. I then have to guess where in the DLL to set a breakpoint.
Previous posts suggest I ensure that my compile options are set to Debug (they are) and that the .pdb file for me DLL are in the references folder of the main program. I don’t know what the reference folder is but the DLL .pdb is in the bin/x64/Debug folder.
The DLL is part of my Solution. In other words, the Solution Explorer for my main Console app allows me to open the DLL source code and set a breakpoint. The only pain in the part is that I have to "rebuild" the dll each time I run or the main program won't see the changes.
Any clues would be greatly appreciated.
Thanks
-Ed
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.
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!
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.
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
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.
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.
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.
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.
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.
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:
Tools > Options > Debugging > General > Untick 'Enable Just My Code'
Go to Assembly Explorer > Open from NuGet Packages Cache
Type the NuGet package name you want to debug in the search field & click 'OK'
From the Assembly Explorer, right-click on the assembly imported and select 'Generate
Pdb'
Select a custom path where you want to save the .PDB file and the framework you want
this to be generated for
Copy the .PDB file from the folder generated to your Debug folder and you can now set
breakpoints on this assembly's library code
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
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 !
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/