Let us assume the following code:
OuterMethod(InnerMethod())
InnerMethod is located in the current assembly that I am debugging so I can step into that. OuterMethod is located in another assembly that has been installed as a nuget package without symbols. I would also like to step into that. When I used to try that in VS2017 I would be met with a page asking me to load the symbols for that assembly, however in VS2022 this no longer happens and the debugger just steps over OuterMethod. How do I get VS to prompt me to locate the symbols for that assembly? Is there a setting somewhere? I am certainly not interested in disabling "Enable Just My Code" - this is not what I want and I remember being able to do this without disabling this setting.
Related
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?
I wrote a tool that many users would use on their computers. I noticed however, that users who do not have visual studio installed, cannot open my executable. The error says that msvcp100.dll is missing. I found in internet a redistributable package from microsoft, that should apparently provide these dlls. My question is: is there another way to bypass this problem? Something like an option in the project properties?
Yes, you can change a compiler setting to link the C++ standard library classes into your program instead of having a dependency on the DLL. Right-click your project in the Solution Explorer window, Properties. Switch to the Release configuration (upper left). C/C++, Code Generation, Runtime Library setting. Select /MT.
Only do this when you only have a single monolithic EXE. When you use your own DLLs then you really need msvcr100.dll and msvcp100.dll so that the runtime library gets shared between all modules.
It is part of C++ runtime and the target machine needs it. THere are couple of ways to address it.
Please check following link from Microsoft MCVCP100.DLL
I am using Visual Studio Professional 2010 and the Team Foundation Server Express (beta). My VS Project (C#.Net / WPF) has been migrated from VS 2008 (without TFS) to VS 2010 (with TFS).
Whenever I apply changes to my code and try to debug my application, I get messages like This breakpoint will not be hit. (in german: Der Haltepunkt wird momentan nicht erreicht. Der Quellcode weist Unterschiede zur Originalversion auf.) and the project is started using the old executable version (the one with the last successful build). No errors occure, the code is OK, but the changes are not applied either.
When I manually cleanup and rebuild my project, everything works quite fine - but there has to be a fix for this issue?
Edit: I just added a new project to my VS solution and checked it in on the TFS Server. Using this new project the problem does not occure. Even when I add the same dependencies I used in the project mentioned above, the debugging and building of the new project works fine without the errors mentioned above.
Maybe this information helps you to lead me to a solution.
It's not clear whether existing answers are not sufficient. I can't know exactly what's causing your problem; but, I can detail some places this potentially comes up.
The first area that I commonly see this is when a project references an assembly directly. You can create a project that creates an assembly. Another project might use that assembly and you can reference by assembly directly (and not add a reference to the "project"). This disconnects VS from really knowing it needs to "build" that referenced assembly first and it will sometimes get out of sync with the debugging symbols (PDB). You can tell if a project has been referenced or an assembly has been referenced in the properties of the reference (expand References in Solution Explorer, right-click a reference, and select Properties). A referenced project will not have a Specific Version property, while an assembly reference will. You can sometimes also tell from Project\Project Dependencies. If you have a reference to an assembly generated by another project but that project isn't a dependency in Project Dependencies, it might be an assembly reference. To fix this, you can usually just delete the reference and add a reference to the project.
I've also find that sometimes breakpoints confuses the debugger. If I have many breakpoints or they've been kicking around a long time, the debugger sometimes does some weird things. If I delete all the existing break points (Debug/Delete all breakpoints) and re-apply them the debugger is usually much happier.
You can find the answer here. The assemblies might be in GAC or a project or some projects need to be rebuild to generate the pdb files again, which are used for debugging. If you don't choose to rebuild it might use the old pdb files.
My guess is that you are putting breaking points somewhere your program can't access them.
Ex:
const int x = 5;
if(this.x == 1)
//do sth <--- breakpoint here
If you are running a mixed mode application (unmanaged native C++ & managed C#), make sure to set Enable unmanaged code debugging in your C# application's Properties window.
You have to rebuild, there isn't an easier way around it.
The program database files (PDB) need to be recreated. You should also have your configuration setting set to debug.
Also the first answer to this question must be of help as well.
This happened to me when I started VS as an admin, and it also happened to me when the project is set to a different architecture than a DLL that I used in this project.
I am creatinig Managed Extensibility Framework extensions for some program. That program uses dll files witch i create. I dont have visual studio project of that program, but i have that program. I can run these extensions using that program, but cant debug them properly.
Is it possible to use visual studio debugger to debug my code?
I found solution to this, thanks!
I found solution to this by my self, but thanks for sugestions.
I can use that app for which i am creating this extension, class libary project.
I press properties on project, then select debug tab and set "start external programm" an set it o that main app. then i press f5 and that app starts and when it uses my extension i can debug it using visual studio debugger. And i forgot to tell that i am creating this in C#.
http://msdn.microsoft.com/en-us/library/68c8335t.aspx
I believe what you are looking for can be found here:
http://msdn.microsoft.com/en-us/library/0bxe8ytt.aspx
According to this article, you could use the "Add Existing Project" dialog in you solution (for your DLL) to add the executable that you do not have the solution for. Because you are using MEF, it might get a bit tricky and you might want to create a new solution for debugging instead. However, this seems to be the general way to handle your situation. Since you have the source code for your DLL, I believe it should allow you to step through your code fully at the very least.
Note: You will need to make sure you have Visual C++ installed in your development environment.
If you are trying to debug the assembly code, then you can use the technique discussed by #BiggsTRC, if you are simply trying to identify why parts aren't being loaded, you could consider looking at the Composition Analysis Tool (mefx). This is a command-line tool for analysing a set of parts and finding out where failures may occur during composition.
First let me say that I can remote debug a release build on the remote computer. I set up my release build much like my debug build but I mostly had to make sure the Debug flag was not set. I've dealt with doing this for a while and finally decided to try and figure out why I had to go through this. I should also mention that my remote debugging experience is limited to this project and the C# program uses a C++/CLI (built with /clr) .DLL to mediate to some critical C++ libs. I don't need to debug the underlying C++ libs but I do need to debug the C++/CLI code. (One reason I mention this is I can't link libs in statically while using the /clr flag).
I recently discovered Dependency Walker so I used it to see what was going on. Turns out with the debug flag set, the linker links in MSVCR100D.DLL and MSVCP100D.DLL, when the flag isn't set it uses the files without the "D" suffix. Now normally I might just copy over my versions of those .DLLs to the remote machine but there's a problem. My dev laptop with VS2010 is a 64 bit machine and the target machine is 32 bit. That means the only versions of those DLLs I own are 64 bit. I have installed the remote debugging for VS2010 (I had this same problem under 2008) on the remote machine but it doesn't include the debug versions of these .DLLs either (I'm not sure why but I'm assuming this is by design). So my questions are:
As a registered owner of VS2010 is there a valid source for 32 bit versions of these .DLLs I can put on the remote machine?
Is there a simpler way for me to get Debug support? That is can I change some other setting that just tells VS to not use the debug version of those two DLLs? The advantage here is the DEBUG symbol would be set and any conditional code using it would work.
The debug versions of the CRT DLLs are all available with the standard Visual Studio installation, including the x86 versions even on 64-bit machines.
By default, they're located in the following path:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist
Under that folder, you'll find two additional folders (x64 and x86) that contain the debugging versions of these DLLs for the respective platforms.
But pay special attention to the name of the folder (Debug_NonRedist). That indicates that these debug DLLs are not redistributable. It's certainly OK for a developer who owns a license for VS to use them when testing his/her code on another machine, but they should not be distributed to client machines and used to run your application. (Sounds like from your question that you know this, but it's worth pointing out anyway for future Googlers.)
Alternatively, you can change which version of the CRT DLLs that a Visual Studio project links to for specific project configurations. That means that you can compile a "Debug" version of your application, but tell Visual Studio to link to the full redistributable versions of the CRT.
To do that:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Debug" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to either "Multi-threaded DLL (/MD)" or "Multi-threaded (/MT)".
Notice here that you're just telling Visual Studio not to use the "Debug" variants of each of these options. They still mean the same thing. The first will dynamically link to a DLL, the second will statically link the CRT into your application. Pick the one most appropriate for your case. (I often find it convenient to configure my "Debug" builds to statically link exactly for instances like this.)
This question is for an older version of Visual Studio, but in case anyone comes here for a newer version (as I did), there is built-in support to deploy the debug DLLs that you need in VS 2013 (perhaps earlier). This is an obvious setting, but it can be easy to miss if one is rushing through things (as I was). So maybe this will help somebody.
In the property pages, under Debugging, when Debugger to launch is set to Remote Windows Debugger, in the property list, there is an option called Deploy Visual C++ Debug Runtime Libraries. Simply set that to Yes.
Update -- as requested, this is to clarify which property pages I'm referring to, by way of how to access them: In Solution Explorer, right click the startup project (the one in bold), and click Properties on the context menu. The Property Pages window appears. In the panel on the left side, expand Configuration Properties, and then select Debugging, the second item under Configuration Properties.
Edit to the Update: I got here via notification, and did not see that I could have just said, "See Cody Gray's answer for a picture of the window," to meet the request for clarification. But, there's the how-to anyway in case anyone needs it.