in one line of my solution which is made of a couple of projects I want to debug one line of code, something like this:
mThisLibrary.DoSthMethod();
but when I put my break point on that line and press F11, the debugger says that "There is no source code available" so I cannot get into it deeper. BUT the source code is there so for example if I click F12 on the method name, I can go to its implementation easily. I am not sure why the debugger cannot get inside that method.
Any ideas?
Make sure that the assembly you are referencing was built with a Program Database File for debugging purposes. If the debugging information is not present, this can happen.
Typically, if the library is part of the same solution, just make sure that all of the projects are being built in Debug. By default, Debug will generate the .pdb files required for debugging, as well as turn off the optimizations that can sometimes cause debugging difficulties.
Related
I'm working on a Xamarin project and when I make an instance of a certain class a bearkpoint inside the constructor never gets hit. Just after instancing the class i call for a function of that class and the Step Into functionality of visual studio 2012 sends me to another totally unrelated function of another class.
When I comment that unrelated function that the Step Into sends me to and call the function again, the Step Into sends me again to a totally unrelated function of another third class.
The functions don't even have the same name.
I already cleaned, rebuild, manuallly deleted bin and obj and nothing works.
Any one knows what is happening?
Note: the Go To Definition (F12) command works as expected but the Step Into (F11) doesn't. I also have it on Debug mode instead of Release.
Well the problem here is obviously your debug symbols are out of sync with your source files. A few ways this can happen:
you're not actively building debug symbols (thus relying on older leftovers), or have optimizations enabled. Note that simply having the debug configuration selected doesn't mean this is not the case -- "debug" is just a label, you can name it puppies for all VS cares. Check the settings.
it's possible there's conflicts with the GAC or the symbol server trying to download wrong symbols. Check your file names that they're not too similar to system DLLs.
You mentioned Xamarin -- I'd triple check that it has the right symbols. It's possible following the call stack through out of date Xamarin symbols is screwing up things when it comes out and back into your code (events).
Another thing I'd try is to cold start your executable, then attach through VS. Go line by line in the Output window and see which symbols are loaded, and equally important, which are failing to load. Check your output folder, check the .pdb file names. Make sure you're not confusing things with the .vshost.exe file, you only care about the executable and any DLLs of your own.
I created 2 instances of same project to apply different changes. So when I open project1 and debug class1, everything is smooth, I can have my breakpoints hit all other debugging features.
When I open project2 and close project1, I try to do same debugging on class1(some lines of the code is different), I get warning that
"the breakpoint will currently not hit. a copy of class1.cs was found in project1.dal.dll, but the current source code is the different from ther version"
When I close the VS completely and reopen the projects or If I clear the Temporary ASP.NET Files, Problem is getting resolved. But it happens everytime for me. so my questions are;
1) I wonder why does it happen and how can I resolve it without closing VS or clearing cache files?
2) I know the option called "Uncheck Require source files to exactly match the original version".. Is it safe to do it? or is there any side affects or disadvantages
It is impossible to debug your code in that way - you are creating different symbols for each build so when you debug one version, the other is not compatible with the previous one.
To make the long story short - you cannot debug one version of code when symbols from another version are loaded.
More info: Fixing "The breakpoint will not currently be hit. No symbols have been loaded for this document."
EDIT:
Check this link also: What is the "Temporary ASP.NET Files" folder for?
I am working on a solution that makes a $.get call to a controller (in a different solution in a different module) inside of a dll. How can I put a break point in the original code of the external project, and actually hit that break point?
Please explain this like you were explaining it to a six year old because im still pretty new to programming.
Make sure Visual Studio is attached to your server process. (if you hit F5, it will be)
Click Debug, Modules, and make sure symbols are loaded for the other DLL.
If they aren't, right-click it, Load Symbols
Open the original source file.
Set a breakpoint.
When debugging my code, I often throw breakpoints in to check the values of local variables to make sure everything is on the right track.
Lately, when I make changes to my code and recompile, all my breakpoints turn into the outline of a circle (instead of a full red circle) and it gives me an error that reads;
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: conditional
compilation or complier optimizations.
What's strange about this issue is that I can simply remove and add the breakpoint and everything will work completely fine.
I am not using any type of conditional compilation or complier optimizations. Does anyone know what this means or how to fix this? It gets quite annoying replacing 10-12 breakpoints each time I compile.
This can happen for a few reasons
The code the debugger is using is different from the code that the application is running
The pdb file that the debugger is using is different from the code that the application is running
The code the application is running has been optimized and debug information has been stripped out.
The code in which you have breakpoints on hasn't been loaded into the process yet (assuming the things above are not the culprits)
If you are attaching the debugger, pay attention to what .net framework it's attaching to (i've had issues with it using .net 4 when code was all .net 2.0)
The assembly you have is also in the GAC. This might happen if say you installed your program so you could debug it, but the installer put the dll in the GAC.
Remove the reference and re-add it (thanks to forsvarir). Typically this occurs when the project that is referenced is not in the solution, and VS will copy the dll from the bin directory of another project. You will know this was the issue when you try to re-add the reference, and can't find the project :)
It's pretty tough to figure out what's going on here, but i would suggest using the fusion log viewer to see what is being loaded and where it's being loaded from and then you can look at the dll and see if it's old code, etc.
Check the project settings
Make sure you don't check the code optimize option, and make sure debug symbols are checked.
Notice that when you change the configuration other settings might change as well and you might not see. Make sure the values are correct for the configuration you are attempting to compile.
Delete the output files
Physically delete all generated DLLs, PDBs and EXEs. Then compile again to generate the files. Sometimes Visual Studio can "get lost" and "forget" to overwrite the output files when you build your solution.
Restart your computer
It usually solves 99% of problems. I already had some issues with Visual Studio and restarting it or the computer solved the problem.
I know this is an old post but still timely enough as I was looking for any other reason I might be getting this problem.
That being said you also might want to check the "Temporary ASP.NET Files" in your c:\Windows\Microsoft.NET\[Frameworks] directories if you are creating a web application as these files are often the cause in my experience.
The use of the precompiler directive #line appears to affect the breakpoints behavior as well, as I've just discovered.
Adding this response to the old thread in case someone like me is tracking down this mystery in an older ASP.Net application. I had one Webform code-behind which did not respond to breakpoints with the "...no executable code..." debugger warning. It was doing my head in as all of the other pages were working fine. I'd done the clean, rebuild, purged the temporary ASP.Net files, no joy.
The culprit with this file was the inclusion of several #ExternalSource directives surrounding some of the member variable declarations. Once those were removed and the project rebuilt, the break point behavior was restored. Those ExternalSource lines were appearing in the generated section of the code-behind. Not sure why they were there.
I'm experimenting with the AppDomain's 'AssemblyResolve' event by hidding the depedencies for an executable file in another folder. The assemblies seem to beloading and executing fine, however debugging seems to be crazy, sometimes it hits my break points, sometimes it doesnt , and sometimes it hits the same code twice(It seems absurd but I'm sure the code is executing only once). I don't understanding how debuggers works but I guess it has something to do with the PDB files. Anyone got an idea of what might be happening and how can I fix it?
Edit:
Let me add that I'm calling methods on the dynamically loaded assemblies using reflection, sometimes the method I'm stepping over throws an exception that only pops at a later time.
Debug + Windows + Modules, find your DLL in the list. Right-click it and choose "Symbol Load Information". It will show you where it found the .pdb file.
Finding the wrong .pdb is not a great explanation for your troubles btw. Maybe you ought to post to connect.microsoft.com. Giving them a good repro would be essential however.