I have a VB6 application that runs dependent on a DLL, to which both of them I hold the source code and are in separate vbp projects.
I know how to use breakpoint and run VB6 debug mode in the application project, but I want to know if it is possible to run debug mode for the DLL?
I saw this article http://www.ni.com/tutorial/4071/en/. Does it mean I first have to compile the application, then in the DLL project I start debug mode by invoking the compiled application and hook it to use the DLL from the project? what does the "TestStand" in the article mean?
Open one of those 2 projects and add another (File - Add Project...) and then set your
application project as start up (project explorer, right click on application project).
Related
I have a C++ DLL project in Visual Studio I've downloaded, which is a plugin module for another existing program (a media Player). The DLL created by this project is saved into the addon folder, is loaded by the media player and works great with no issues. However, I would like to be able to step through the code in the library while the player is running to understand how the code works.
The problem is that when I setup the project to launch the media player and step through the DLL project code, it starts fine and I can set breakpoints. But at certain times, the Visual Studio debugger tries to access other loaded DLLs inside the media player, which I don't have source code for, and it crashes the whole thing with an "access violation writing location blah blah blah" error. I have no interest in trying to access any other libraries the program is loading other than the one I have the source code for, so is there any way to prevent the Visual Studio Debugger from trying to hook into these other libraries? I know the error is not due to anything in the DLL project itself because it runs absolutely fine if I just tell it to "Start Without Debugging."
I have the source code for, so is there any way to prevent the Visual
Studio Debugger from trying to hook into these other libraries?
Please try these steps:
Suggestion
1) check Enable Just My Code under Tools-->Options-->Debugging-->General
2) enter Tools-->Options-->Debugging-->Symbols-->choose All modules, unless excluded and then click Specify excluded modules
then input the name of the dlls you want to exclude. Their symbols will not be loaded when you debug your application.
3) do not forget to uncheck option Warn if no user code on launch(managed only) under Tools-->Options-->Debugging-->General
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
One of the awesome things I remember in Visual Basic 6 from years ago that you could just load up an ActiveX exe project into the IDE, set a breakpoint, press Run and whenever someone (either an EXE or a project in a different IDE) called that DLL, your breakpoint would hit.
Is something like this possible with Visual Studio 2008? Can I load up a WinForms project into one IDE and a Class Library project into another IDE and have the WinForms project call the Class Library project?
In VS you cannot attach two debuggers to the same process (it is possible to attach VS and WinDbg to the same process, but not in the default manner).
Point is, you don't have to use two debuggers or include the auxiliary project in your solution. Immediately after the dll load you'd be able to step through it and set breakpoints in it as if this was the solution you just compiled - all you need is the dll's debug symbols (pdb). Typically the dll load time is at process launch - but if it is loaded dynamically you might want to break immediately after the LoadLibrary call and only then set breakpoints in the dll. You can set the breakpoints in advance, but you'd still have to break somewhere after the dll load to enable the breakpoints to be translated into instruction addresses.
[Edit:] This does (I hope) answer the question as you put it, but it would not reproduce the VB experience you describe. AFAIK there is no way to set breakpoints in a library that would be applied to every process that loads that library. The closest I can think of is for you to set a MessageBox displaying the process ID in the library initialization routine (essentially DllMain), then manually attach a debugger to that process and set breakpoints as desired.
You can:
1) Add the project with the DLL to the solution with the EXE (this not quite what you're asking).
2) You can attach the IDE with the DLL project to the process running the EXE from Debug -> Attach to process. I never tried to attach two debuggers to the same process at the same time though.
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.
I have a Visual Studio 2008 solution with two projects in it. A C++ DLL and a Csharp application.
The Csharp application uses [DllImport] to access the functions in the DLL, and has a dependency set on the DLL.
For some reason, setting the dependency isn't sufficient to cause VS to copy the DLL to the build path of the app. So the app project has a post-build event which causes the DLL to get copied. (If anyone knows of a cleaner way of doing this, please let me know!)
The problem I have is that when I make a change to the DLL code, then attempt to run the Csharp application in the debugger, VS2008 fails to realise that the DLL must be rebuilt (and re-copied).
I have to force a re-build of the Csharp application (ie by explicitly choosing build, or by "touching" a .CS file).
Does anyone know how to tell Visual Studio to do the right thing?
Edits:
I am using project dependencies. They aren't working correctly.
I am using a post-build event to copy the DLL across.
The issue is that, if you simply choose to debug the application, Visual Studio fails to recompile the changed C++ project, despite the fact that there is a dependency in place.
I know the dependency is working, because if I choose "Build" (as opposed to "Debug") the C++ DLL is built.
"Build" and "Debug" do different things. In Tools - Options - Projects and Solutions - Build and Run, there is a checkbox "Only build startup projects and dependencies on Run". This is checked by default. So, if VS isn't recognising the DLL as a dependency, it won't build it when you choose "Debug".
I don't have VS to hand (only Express), but you could try adding the C++ DLL as a reference rather than a dependency.
Hmm... so I haven't done this exact thing before but I just threw together a C++ lib project and a C# winform project in the same solution. I right-clicked the solution, chose Properties and then under Common Properties->Project Dependencies, I made the C# one depend on the C++ one.
When I make a mod to the C++ one, it will ask me if I want to rebuild the C++ one. There's a "Don't ask me" checkbox too.
Maybe my test is different than your situation, but it seemed to work when I did that.
Hope that is some help.
Assuming the DLL project isn't used in another solution, why not put the post-build event on the DLL app project, so it is always copied?
I've not tried, but can't you do this with the build order?
I have experienced this same issue with applications that have DLL project dependencies. It seems to me that the problem is that Visual Studio only launches the post-build event if it has to recompile something in the Application's project. So, if you modify the DLL source without modifying any of the headers that the Application includes, then the Application is not recompiled because from it's perspective the DLL is the same. Since the application is not recompiled, the post-build event is not triggered. So, the Application is left with out of date DLLs. I have yet to come up with a good solution to this problem.