Cross-solution debugging with Visual Studio - visual-studio

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.

Related

How to debug .NET5 sources when you don't control the starting point sources

So I have an interesting situation. I don't know how to debug my .net 5 code, because the starting point executable is not an executable I control. I am provided with a .NET5 DLL to which I can write plugins for. Because the process is dotnet.exe and my DLLs are not part of the starting point project, I cannot seem to get the visual studio debugger to actually debug anything I write.
I can attach to the dotnet process, but my breakpoints say they won't work because the symbols haven't been loaded for this project.
I have followed the miscrosoft documentation, but it only applies to a single "layer" of project, and doesn't seem to have any information about debugging a project that is a layer above the layer bring run by dotnet.exe.
I hope I described that well enough.

Ignore other DLL Files when debugging DLL Project with target application (Visual Studio 2019)

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

Visual Studio breakpoints only work on second debug attempt

I have a VS 2010 solution with a web application project, and several class library projects to which the web app project has project references. When I am trying to debug the code for one of the class library projects through the F5 debug build process, the Modules window normally fails to load the symbols for the DLL in question, or if it does, the breakpoints are ignored anyway. However, on the second attempt at an F5 debug build, the breakpoints usually are recognized, and the code will halt in the required location.
I have tried ALL sorts to fix this issue - all the usual solution cleaning business, repeating the referencing procedure. I didn't see this issue until I upgraded to VS 2010, after which I rebuilt a new VS2010 solution from existing projects. I am beginning to think this is some sort of timing bug in 2010, as I am making no changes between the first and second attempt - it's as though VS 2010 is disregarding the dependendencies in the build configuration, and starting the web app build before the PDB for the class library is ready, or before it can locate the PDB for the class library.
Has anybody seen similar behaviour in VS2010? As you can imagine it is adding considerable amounts of 'productivity killing' time to my debugging, having to build everything 2 or 3 times just to get the breakpoints to be recognized.
Thanks if you can advise.
Try erasing the bin and obj folders between runs. does it help?
I have similar issues with a web server which does not get changes made to the configuration file on VS2010.

Break point not working and modules not loading dll files in VS 2010

I am using VS 2010 professional [64bit - Windows 7] and in my solutions, i have 3 class library project and 1 wcf service projects are there. All these dll's are refereneced in my WPF applications. For the last 1 year, it was working fine and i was able to debug the all the referenced projects. But from yesterday itself, debug is not working all of a sudden.
When I put a break point on a class in the wcf project, it says breakpoints cannot hit as the source file is different from....etc.
When I checked in the Debug --> Windows ---> Modules window, all those projects dlls are not seen there and says no pdb files are available ???
But in the WPF bin\Debug folder, i have all the referenced dlls and their pdb are ther.
What could be the problem ?
Even I am not able to debugg the wpf project as well. For getting break point or debug, each time i have to clean the solution or project then rebuild it again. Then i will be able to debug the WPF project.
In the case of referenced dlls, I removed the dlls and added the new compiled dll again and copied that pdb files to the wpf project exe folder. Still no use !!!!
I have changed the options in the Debug and Options [disabling and enabling the Just my code options etc]. But still it is not working.
This is not only my problem. One of my colleague also have this problem we took the whole latest solution code from TFS. SO I changed the Local code path to a new folder and took the latest code from TFS again. Still the problem exists !!
I am able to run the application. But debug is not working. In the WPF project, all those dlls are referenced properly.
Can anyone help us ???
I guess I don't have enough points to comment to ask specifics, so this may or may not solve your problem but I'll take a crack at it. Also, there appear to be other questions about this. So I would check those out first to see if they will help.
This question was solved by adding configuration to tell the program which version of the framework to use during debugging.
Why doesn't VS2010 debugger stop at my breakpoints?
Why does Visual Studio 2008 skip over my break points?
If those don't help, I'll give it a go.
When I put a break point on a class in the wcf project, it says breakpoints cannot hit as the source file is different from....etc.
This sounds like it could be one of the following issues:
Remote debugging and Visual Studio does not know where to load the symbols from or they are out-of-date
Need to clean and rebuild (which you seem to be doing)
The server you are running your WCF service on is not getting the updated DLLs and PDB files. If it's IIS Express, try killing the process between builds.
Also, make sure you are building in Debug mode and not Release mode. While building Release mode will generate the PDB files if it's set to do so which will allow you to debug an application, the code may be optimized as well which can cause breakpoints to be missed.

DLL response is too slow in Visual Studio

I use a 3rd party DLL in my VB.NET project (VS2005) that responds to slow and give wrong values in debug mode. In run-time mode everything works as expected.
I do understand that there are something going on in the debug mode which makes the DLL communication slow. This behavior makes it hard to debug the application correctly.
Is there any way to force VS to communicate with the DLL in "run-time" mode during debugging but let the rest of the project be in control of the debugger?
I found a setting that resolved my issue:
Project Properties > Debug > Enable Debuggers > select "Enable unmanaged code debugging".
Now the DLL communication flowed smoothly. The DLL I use is a middleware between my app and a USB device. There is no Debug/Release version of the DLL.
Change the debug DLL for the release one, either by switching files or by telling the linker/build process to only use the release one, but like the comment above I'd suspect there's some funky stuff going on in both.

Resources