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

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

Related

Visual Studio ignores breakpoints in different file

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.

How to create a managed plugin for Unity with Visual Studio Community for Mac

I'm going to create my first managed plugin for Unity (2018.2) using Visual Studio Community for Mac (7.6.11 build 9).
I've read the documentation but I think that the step-by-step instructions are not meant to be followed on Visual Studio Community for Mac.
As you can see in the screenshot below, I've created several projects using each and every library template available.
All of them compiled successfully to a DLL targeting versions of .NET framework that are incompatible with Unity.
The only project I could change the .NET framework version to match Unity's 3.5 is the one based on the Other > .NET > Library.
Everything works fine but I'd like to know if the assumptions, the process and the final result are correct. Can you tell me, please?
I don't know the difference between the "Class" and the "Class Library" option but you're supposed to use the "Class Library" option. This is not the main point of this answer.
Two future issues you haven't solved yet:
1. Referencing Unity's API.
If you ever have to use any Unity library or API in youir plugin such as Vector3, you need to add Unity's UnityEngine.dll to your library settings. If you don't, you will run-time exceptions.
Go to Project --> Add Reference ---> Browse ---> Browse Button
then select <UnityInstallationDirecory>\Editor\Data\Managed\UnityEngine.dll. You can now build your managed plugin. Since you're using Mac, this path is different on your OS. On Mac, this could be /Applications/Unity/Unity.app/Contents/Frameworks/Managed/UnityEngine.dll. You just have to find where UnityEngine.dll is located.
2. Invisible stack trace
With your current setup, if you run into error with your managed plugin, the stack trace won't be there. You won't have the file names and line numbers and this makes is very hard to debug your plugin code.
When you build the project, Visual Studio generates a PDB file instead of an MDB file. Unity can't use this directly. You have to convert the PDB files into MDB files.
From command line, run this:
<UnityInstallationDirecory>\Data\MonoBleedingEdge\lib\mono\4.5\pdb2mdb.exe UnmanagedPlugin.dll
Again, the path might be different on Mac, you just need to find "pdb2mdb.exe" that converts the PDB files into MDB files.
After that, copy the MDB and dll file into the "Assets" folder in your Unity project.

Vs2017 Source Not Available

I´m trying to debug a System.Net.Http.Formating.dll, by clicking at the stack trace:
System.Net.Http.Formatting.dll!System.Net.Http.Formatting.JsonMediaTypeFormatter.WriteToStreamAsync.AnonymousMethod__c()
I´ve the "Just my code disabled" and I have the following symbols servers:
https://nuget.smbsrc.net
http://localhost:33417/ (dot peek)
Microsoft Symbol Server
I do have the pdb available, however I get the following error/image.
How to properly overcome it?
Why is it such a hassle to debug third party source code at Visual Studio?
After following the link pointed by #Jack Zhai-MSFT I was finally able to understaand the reasons why the .net framework couldn´t be debugged.
It turned out that the symbols were being downloaded without their respective source, because I was pointing to Microsoft Symbol Server instead of http://referencesource.microsoft.com/symbols
Then, my following attempt was to uncheck the "Microsoft Symbols Server" or to change the order at the Symbols menu. To my surprise, I couldn´t delete it, nor change the order, and, even after it was disabled the symbols were still fetched from there.
Perhaps this is a VS2017 community bug.
What I did next, that actually solved it:
Deleted my symbol cache that had misleading pdbs without source
Enabled just my code flag, disabling “Enable .NET Framework source stepping” and started the app, on debug mode
Paused at a breakpoint in which, at the stack, I had access to the code I wanted to debug
Double clicked such stack, and then hit Load Symbols.
This time around, for some reason, the Microsoft Symbol Server was skipped, and the right pdbs were downloaded
Note that, still, I couldn´t download some "optimized symbols" like system.net.http, but I´ll try to figure that out next
Also, I setup the symbols servers using that as a reference, which helped me to promptly get any third party symbols (Except .net)
https://www.symbolsource.org/Public/Wiki/Using
EDIT:
With the help of dotPeeker I was able to get all the missing pdb files by:
Loading these dlls into dotpeeker (ex: System.Net.Http)
Load one of the source files from that DLL
Hit Generate PDB and store it into the same cache folder as VS2017 uses
PHEW!! What a hassle for something that should have been trivial!
To debug third party source code, you could use the .NET Reflector or dotPeek with VS.
Reference:
Is it possible to actually debug 3rd party code using the source decompiled with dotPeek?
Update:
If you just want to debug the .NET source code, see: How do I debug .NET 4.6 framework source code in Visual Studio 2017?

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.

System.IO.FileNotFoundException when trying to load DLL

I'm not a a very experienced Windows developer, so I hope this all makes sense.
I created a Managed Assembly DLL using Visual Studio 2010. The DLL (Plip.dll) contains a C++ class that is using System.IO.SerialPort class to do some simple communication over a serial port.
In a second Visual Studio project I created a simple GUI that uses the class found in Plip.dll. In my GUI project I have the line : #using "Plip.dll" . In the Project Properties I set the 'Resolve #using References' value to the correct location of Plip.dll. The GUI builds just fine. If I copy the GUI.exe and Plip.dll to the same folder, the GUI runs just fine on my computer.
The problem I am having is that when I copy both files to a second computer, I cannot get the GUI executable to run. I get the following error : "System.IO.FileNotFoundException. Could not load file or assembly "Plip.dll" Vesion=.... ". I get this error even though both the exe and dll are located in the same folder.
Any suggestions on how to resolve this issue? Is there some option I need to set in my GUI project to load the DLL correctly at run time?
I suppose the problem is not the Plip.dll, but it's dependencies.
Use Dependency Walker on the second computer to see if it needs any other dll's (they might be installed in System folder or in %PATH% on your development computer, but not on the other).
If this second computer doesn't have Visual Studio installed, you are probably missing Microsoft Visual C++ 2010 Redistributable Package (you need to install it on the other computer)
Also make sure that you compile in Release because debug builds need debug dependencies.
I found the answer to this problem to be much simpler than Dependency Walker (but admittedly, that was fun to look at).
In my case, the issue was a mis-match between the .DotNet versions in the DLL and with the application's .net version. This was caused by building the "class library" using .DotNet 6.0 (dot net core?).
Instead, the entire class needed to be re-built using "Class Library (.NET Framework)"
enter image description here
I wrote an article on this problem.
https://keyliner.blogspot.com/2022/09/visual-studio-c-linked-dll-exception.html

Resources