I have a project(A) that references an assembly from an external project(B) class library that is located in another vs solution.
I have yet to understand how i can efficiently debug the class library from B while running the program from project A. Is there something I have to enable on project B such as debug info etc so I can step-into at debug time from A?
Try disabling Just My Code (JMC).
Tools > Options > Debugging
Uncheck "Enable Just My Code"
By default the debugger tries to restrict the view of the world to code that is only contained within your solution. This is really heplful at times but when you want to debug code which is not in your solution (as is your situation) you need to disable JMC in order to see it. Otherwise the code will be treated as external and largely hidden from your view.
EDIT
When you're broken in your code try the following.
Debug > Windows > Modules
Find the DLL for the project you are interested in
Right Click > Load Symbols > Select the Path to the .PDB for your other project
Assume the path of
Project A
C:\Projects\ProjectA
Project B
C:\Projects\ProjectB
and the dll of ProjectB is in
C:\Projects\ProjectB\bin\Debug\
To debug into ProjectB from ProjectA, do the following
Copy B's dll with dll's .PDB to the ProjectA's compiling directory.
Now debug ProjectA. When code reaches the part where you need to call dll's method or events etc while debugging, press F11 to step into the dll's code.
NOTE : DO NOT MISS TO COPY THE .PDB FILE
This has bugged me for some time. What I usually end up doing is rebuilding my external library using debug mode, then copy both .dll and the .pdb file to the bin of my website. This allows me to step into the libarary code.
I run two instances of visual studio--one for the external dll and one for the main application.
In the project properties of the external dll, set the following:
Build Events:
copy /y "$(TargetDir)$(TargetName).dll" "C:\<path-to-main> \bin\$(ConfigurationName)\$(TargetName).dll"
copy /y "$(TargetDir)$(TargetName).pdb" "C:\<path-to-main> \bin\$(ConfigurationName)\$(TargetName).pdb"
Debug:
Start external program: C:\<path-to-main>\bin\debug\<AppName>.exe
Working Directory C:\<path-to-main>\bin\debug
This way, whenever I build the external dll, it gets updated in the main application's directory. If I hit debug from the external dll's project--the main application runs, but the debugger only hits breakpoints in the external dll. If I hit debug from the main project, the main application runs with the most recently built external dll, but now the debugger only hits breakpoints in the main project.
I realize one debugger will do the job for both, but I find it easier to keep the two straight this way.
If you have main (project A) and external library (project B):
Open (project A) solution in Visual Studio.
Right click on solution -> Add Existing Project -> then select the .csproj file of your external library (project B).
Again in visual studio right click on (project A) -> Add -> Project Refference... -> and then add checkmark on your external library which you want to debug (project B).
Finally place brake-points in (project A) where your external library (project B) is called and run with F5.
[according to Martin Beckett, the guy who send me this answer ]
You can debug into an external library.
In the project settings tab look for 'visual studio directories' in the 'source code' field include the path to the openCV sources. Then make sure that the .pdb files for each of the debug dll are in the same directory as the dll.
NuGet references
Assume the
-Project_A (produces project_a.dll)
-Project_B (produces project_b.dll)
and Project_B references to Project_A by NuGet packages then
just copy project_a.dll , project_a.pdb to the folder Project_B/Packages.
In effect that should be copied to the /bin.
Now debug Project_A. When code reaches the part where you need to call dll's method or events etc while debugging, press F11 to step into the dll's code.
I was having a similar issue as my breakpoints in project(B) were not being hit. My solution was to rebuild project(B) then debug project(A) as the dlls needed to be updated.
Visual studio should allow you to debug into an external library.
The quickest way to do this on a one-off basis is to open the Proj B file directly in the Visual Studio instance in which you are editing and launching Project A (File => Open => File). You don't need to add the file to the solution. Just having it open in the editor will let you create your breakpoints directly in the Project B file.
Related
I'm debugging .Net Core in Visual Studio, and the breakpoints are working fine in the current file, but when a method from a different file is called, its breakpoints aren't being hit. I'm not familiar with Visual Studio because I usually debug in VS Code so I'm sort of lost.
I've googled it, but can't find any info - is it possible that VS ignores breakpoints in files other than the current one?
(It's ignoring the Debug.WriteLine I added as well but I just need to confirm if it's really not hitting breakpoints rather than not actually calling the method.)
Visual Studio ignores breakpoints in different file
If this issue is as phuclv's descroption, a net core project references a c++ Dynamic link library, you can follow the link, open the c++ project-->change it as mixed and then open net core project, choose Enable native code debugging. Also,
If you create the project in vs-code and then migrate it into VS2019,since vs-code is different from visual studio, you should try these steps:
1) delete the bin and obj folder first
2) make sure that these two options are checked under Tools-->Options-->Nuget Package Manager.
3) Try disabling Just My Code under Tools--> Options --> Debugging-->General
4) If the file is from the other project,please add reference to these projects by Right-click on the Dependencies-->Add Reference-->these projects or just copy these projects's dll and pdb files into the main project's output folder(Bin).
5) Use Debug mode to debug your project.
In addition, if these do not work, please try to create a new net core project in vs and migrate your old project into the new project to test whether this issue persists.
I have included a dll file into my project. I reference it from a library folder where also resides dll's pdb file. When I compile I see both dll and pdb copied to main project's bin folder. On small projects this works wonderfully and I can debug into the dll with no problems. Sometimes, however, in larger projects, VS keeps asking for specific cs files even though their pdb file is included in the projects bin folder. That's ok if I can find those cs files, but it's annoying.
Why is Visual Studio sometimes asking for cs files and sometimes not?
It tries its best given the information it has, but sometimes that information is incomplete. When its ready to give up, it gives you the opportunity to provide the file, just in case you know better.
PDBs generally store the path to the file, as it was when msbuild was invoked to build the DLL. If the paths have changed (e.g. you're on a different machine to where the DLL was built, or just that files on the file system have moved) then the path information doesn't do it much good.
There is a process called source indexing that can embed enough information into the PDBs so that visual studio can re-locate the source files in your source control system (so that you get exactly the correct file as it was at the time of the build) but this is usually an extra step that has to be performed to modify the PDBs after the build has occurred.
Try this (from MSDN Forum)
Tools -> Options -> Debugging -> Symbols -> Empty Symbol Cache (button)
then
Tools -> Options -> Debugging General-> Enable Just My Code (checkbox)
and start debugging again. This should solve the problem if it was initiated by accidental third party components debug symbols that doesn't contains sources but storye only file paths.
I create a project,and I set "DLL" mode on output. I want debug my dll project , so I do "attach to process",(at the beginning ,I can not find "attach to process",but after I install the "GUN debugger plugin monodevelop",I can find it in the RUN menu.)
I debug a DLL project which has already attached to a process, but it always stop at the Line: "b7799424 pop %ebp" in the "Disassemly+"file.
Application output shows:"0Xb7799424in__kernel_vsyscall()".
I can not debug the DLL program.
Anyone can give me some help to this trouble.
Demi
The method of debugging the DLL (or library) project in Monodevelop IDE :
Instead of attaching to the exe that references your dll have MonoDevelop launch the exe for you. The trick to getting MonoDevelop to launch the exe for you is like this :
Create an empty solution.
Add your .exe project to this solution.
Continue to add your .dll project to the solution.
Set that your .exe project as the startup project.
Set the output path of your dll project in the debug file of your .exe project .
Build the entire solution and select Debug from the Run menu.
The MonoDevelop will launch your exe in the debugger and should be able to break at breakpoints within your dll project.
This methode is referenced by this webpage.I tried this method and it can work.
Hope this can help other people.
Demi
It looks like you are using the GDB debugger which is pretty low level, maybe you should try with the soft or hard debugger, instructions are found on the monodevelop website
I remember being able to do this but I must have changed something as I can no longer view an external projects source even though the pdb is with the reference. I can step into external functions when debugging but I can't go to them using "Go to implementation/declaration"
This will work if you have a separate class library Project as a part of your Solution, and you added a reference to the Project, not the compiled .dll.
You cannot step into a .dll when debugging.
It's all in how you add the reference.
I have a C# project in VS 2005, with a reference to Foo.dll, a library of C++ .NET code, at c:\Foo\Foo.dll. It shows the reference in the Object Browser properly, but for a given object + method, I can't figure out how to navigate to the source for it inside of Visual Studio.
I've built Foo.dll myself from source on my local machine, and Foo.pdb is in the same location as Foo.dll, at c:\Foo\Foo.dll.pdb. I don't have a project for Foo in the solution I'm working within.
Looking at a stack trace from my C# app, I can see that it knows exactly where the source is on my system - I see a line that looks like:
at mycompany.Foo.SomeClass.SomeMethod() in c:\src\foo\src\SomeClass.cc: line 123
This is the right location for that source file, but I can't figure out at all how to easily have VS open SomeClass.cc. Does Visual Studio require that Foo be setup as a project in my solution in order to easily navigate to the source code?
Thanks!
Can you include the project in the solution and build by 'project reference'?
Is your application loading Foo.dll from the patch c:\Foo\Foo.dll? I'm guessing you actually have a copy of the dll in your application's bin folder. If that's the case, the .pdb file will need to be in the same location. Once you do that you should be able to step in to the code - Visual Studio should prompt for the code location.
One other thought - Under Tools > Options, look at the Debugging section. Under the General sub-section, see if "Enable Just My Code (Managed only)" is checked. If it is, uncheck it and then try to debug.