I'm extremely new to Dotpeek. Perhaps I'm missing something but everything seems to be in order:
The Modules I want are loaded:
Everything appears good in Dotpeek:
My breakpoints are set:
Yet I keep getting this message when I land on a breakpoint in the decompiled pdb:
The only reason I can think of is that this is Microsoft's proprietary software and they must have a way to keep people from doing this. Is this the case? If not, how can I get this working?
I have searched and found similar posts but the solutions aren't working here for some reason...
Creating source code from compiled code (DLLs) is a feature of dotPeek. Visual Studio does not have that feature.
Some tools can integrate in Visual Studio (such as Red Gate Reflector, a commercial tool), but AFAIK, dotPeek does not integrate into VS until now.
So, no, you can't see source code of arbitrary DLLs in Visual Studio.
We usually don't recommend software here, but perhaps dnSpy has what you're looking for: debugging and discompiling capabilities.
Per the docs, you might have missed this step:
make sure to "In the Visual Studio options, go to the Debugging | General page and clear the Enable Just My Code checkbox.
Through trial and error, I have found that even with everything properly setup, creating a breakpoint manually with "New > Function Breakpoint" does not always work. The breakpoint triggers when expected, but I get "Source Not Available" as you do.
Workaround
My workaround is to find a way to step-in to where I need to be, then set the breakpoint normally (click gutter or F9). Sometimes I can do this from my own code, sometimes I have to find another method in the library where a manual breakpoint does work.
It's easy to tell whether a manual breakpoint is going to work, without even hitting it: with the debugger attached, after creaing the breakpoint using "New > Function Breakpoint", if "Language" and "File" are correct, it will work. Or when double-clicking the breakpoint, if it takes you to the file, it will work.
Details
Here's a comparison of my breakpoints, one set by stepping in, the other set manually. The one set manually shows no File, and when hit displays "Source Not Available":
When I exported these breakpoints to XML, I notice the following differences:
Breakpoint that works (stepped-in, then set):
<LocationType>SourceLocation</LocationType>
...
<FileName>C:\Users\MyUser\AppData\Local\JetBrains\Shared\vAny\DecompilerCache\decompiler\7391115F-C184-4D01-A933-DF771669B14D\0f\2317d014\HttpCacheAttribute.cs</FileName>
...
<BreakpointType>PendingBreakpoint</BreakpointType>
Breakpoint that doesn't work (manually created):
<LocationType>NamedLocation</LocationType>
...
<BreakpointType>BoundBreakpoint</BreakpointType>
...
<ModuleName>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\e1238e8c\6a0ff27b\assembly\dl3\a01be3d2\00ba5bf4_8fe7d601\CacheCow.Server.WebApi.dll</ModuleName>
Related
I found myself in this same problem than here, I'm using windows forms in a dll (this is for an Autocad plug-in) and I cannot debug my code because I receive "The application is in break mode. your app has entered a break state, but no code is currently executing that is supported by the selected debug engine". I have tried every recommendation in this list and none worked for me. One odd thing was that I can break in the constructor but the events that use a controller/config object get that page.
Any ideas why this may be happening?
thanks in advance
In my case, I was receiving this same message when calling an MVC API endpoint, and it was also throwing a stack overflow exception. The cause was an object property in an external dll which was written with a backing field. The set accessor of the property was accidentally written to set the property and not the backing field which caused an infinite loop, hence the stack overflow exception. Note the missing underscore in the setter.
private string _Prefix;
public string Prefix
{
get { return _Prefix; }
set { Prefix = value; }
}
Though your issue may not be exactly as mine, something similar is occurring in an external dll.
Restarting visual studio solve this for me.
I've never worked with Autocad but I've made a few plugins for Solidworks and for Creo Parametrics. Here what I usually do when my breakpoint is not working:
Make sure that on build tab of project settings
DEBUG constant is on
Debug info set to full
Optimized code is off
To the code in question add System.Diagnostics.Trace.WriteLine("something unique"); and run it without visual studio attached to make sure your code is actually being called. Check with DebugView utility from sys internals.
Make sure right copy of your dll is loaded :
Run your solution from visual studio as you usually do
Check if you are attached to the right process.
Do actions in Autocad that trigger your code.
Click on Break All button in Debug toolbar in VS
Open Debug->Windows->Modules window and make sure that your dll is present in the list, path is correct and there's pdb file for your dll right next to it.
Add calls to
System.Diagnostics.Debugger.Launch(); and
System.Diagnostics.Debugger.Break(); to your code.
Hope this helps, let me know if you need clarifications for any of the steps.
I have this problem on my Visual Studio 2017 15.8.6.
Maybe my code setting is "Allow unsafe code", but it has the same error code.
The solution is click Tool > Options > Debugging > General > Use Managed Compatibility Mode and activate it.
I found the solution from this forum.
For me, the solution was to install the Oracle.ManagedDataAccess.Core NuGet package only. I had Oracle.ManagedDataAccess installed as well and I needed to uninstall them to fix the Break mode error.
I also had the same issue. After doing some analysis found out that some of the dependent projects were not built properly. Rebuilding all the dependent projects worked for me.
I can't seem to be able to debug. When I try to, I don't get any build errors, and the layout changes to debug mode, but the windows never pops up. I have an orange bar at the bottom of VS, which I think is standard, but nothing happens after that. It's not just in the project I'm working on. I have started a new WFA and tried to debug without adding any code and the same thing happens. Anybody have similar issues?
I've encountered this before. Not sure what causes it, but generally it is one of a couple of things to fix it.
make sure you are building in debug and not release
close VS, go to the project's dir and delete the obj and bin directories. Reopen in VS and rebuild.
there is an option under tools - options - build (iirc) that allows for checking if source is same as code file. However, you should see a message in output window if this is the case.
on the project properties in the build (iirc) you can throttle the pdb file from full debug symbols to no pdb at all. If you are not the only person on the project check this setting still has full pdb enabled (low probability this got changed though)
make sure you're on the right platform that you are building to (x64 vs x32)
...lots more, but a starting place...
Addendum as per comment...
So, those messages are good. It is saying there are no problems (but it sounds like you already know that :) ). I would start with the general debug options you mention. Do this on a hello world app. That way you can troubleshoot the lowest common first. Here are my settings. Try to match them and see if that works. For example, I know "ask before deleting breakpoint" is irrelevant, but "break all processes when one process breaks" is important. So, I just added them all to make it easier to troubleshoot.
ALso, make sure you are getting a red dot here like so in your code in visual studio (I've seen instances where VS won't let you put this here):
Right click on the project
Click on the properties.
go to web.
Check the Box for Enable Edit and Continue .
Hope that helps :)
This is an issue with visual studio 2012. It doesn't ALWAYS show up. I've found that if you stop your program during debugging, or if you close the console window, this will almost always trigger.
However, letting it run to completion isn't enough either, sometimes this just happens.
Also you can build your application in debug mode, go to the output, run the program, and attach to that process. :P
Amazing answers already given but they dont help in the purpose. So here is my finding, no matter if i am late in answering, but it really works for me.
Even if you are developing a web app, just go to the website properties by right-clicking the project and then you see a "Web" tab on left as i have highlighted. Then just check the box saying "Enable Edit and Continue". Thats all you need to do. it works for me!
I had a similar problem, and solution was absolutely dumb. VS was confused with two instances of Internet Explorer in “Browse with” setting. So, I set Google Chrome (any browser) as default, and then set IE as default again. It deleted the other instance of IE (only one remained) and debugging was enabled.
Hope it help!
I had a similar issue.
I added up:
using namespace std;
and this solved the problem
For me, uninstalling the Redgate's Reflector plugin that had expired fixed it. I spent more than 4 hours uninstalling, rebooting, reverting to older code, etc etc..
When my default browser was changed to CHROME, I could no longer debug my User Interface. Setting IE back to the default browser fixed it. Alternatively you can attach the process plug-in during debug.
I had the same problem with my desktop application and as this forum says you should mark your project as a startup project, since visual studio has unmarked. It worked just fine for me an I believe it will help other people that may have this problem, since I believe you have finished this project.
One of my VB .NET Winforms projects wouldn't allow debugging.
This was due to the configuration manager set to 'Release' even though the toolbar dropdown indicated 'Debug'.
You need to select the mode dropdown and select the last option 'Configuration Manager' and ensure that the main project is set to 'Debug' and not 'Release'
Install Microsoft SSDTSetup.exe 450Kb and Close the SSDT tool during install. After installation open the SSDT tool and execute the script task and Component with breakpoint. Worked for me
try checking your output without debugging
Ctrl + F5
good luck
I am working on a C# and Silverlight project and every once in a while I run into an issue where my breakpoints are no longer getting hit when I debug. In the editor they are not turning transparent so I know the correct code is loaded and being run.
An example would be:
I have Value with a getter and setter and it is bound to a control. When I put a breakpoint in the setter and I change the value of Value from the control the breakpoint is not getting hit.
I know that an IIS reset fixes this problem but I would like to know the cause. Does anybody else find similar behavior? If anybody would be able to point me in the direction of a possible cause that would be much appreciated.
There is an option in Visual Studio 2010:
Tools -> Options...
Debugging -> General
"Step over properties and operators (Managed only)"
Make sure this isn't checked. This assumes that the breakpoint is a solid red circle, indicating that VS has found debugging symbols for it.
Alternatively, these elements of code could be decorated with one of various debugging attributes, namely DebuggerStepThroughAttribute, DebuggerNonUserCodeAttribute and DebuggerHiddenAttribute. These may stop the debugger from going into the method, even if a breakpoint is there.
Of course, if the code you are debugging has been optimised, it may look like it's missing lines. I'm not sure what happens if you try to breakpoint a line that has been optimised away.
If the breakpoint has gone hollow (not solid red), then Visual Studio likely cannot find the debugging symbols for the code.
If a reset fixes the issue, perhaps there are differences between the code being debugged and the original source file / symbols, there is an option to make this less strict:
Same options area as above.
"Require source files to exactly match the original version"
Many times i face this problem though while on winforms apps. So simple thing i do is, restart VS prior to Clean and Rebuild the solution. Then if nothing works out, just delete the bin directory and let rebuild again. The last option i do is restart machine.
I've had this problem recently. While I did not find the exact cause, a simple fix was to check the app is running in debug mode (as opposed to release) and clean / rebuild the solution.
Found this question while trying to understand why my own project's breakpoints weren't being hit while trying to run code in vs2010
Solved it by looking at the project properties under Advanced Compile Options and setting Generate Debug Info to Full.
Might be worth mentioning I jump into code I wish to debug by using the very handy TestDriven.net's "Test With -> Debugger" via a right click on the function I wish to debug.
(At least) Two potential causes: Visual Studio options, or ReSharper options
Example: if I break at some call like Console.WriteLine(myVar.myProp), and I also break inside the myProp getter, the breakpoint inside the getter will be completely skipped if the following settings are still turned on.
For the Visual Studio Options:
And for the ReSharper Options:
So, turn these off to avoid datatips from causing your breakpoints to be skipped.
I am unable to put a breakpoint.
I am getting the message in the breakpoint like:
"break point will not be currently hit, no symbols are loaded"
there are a few solutions. The problem is that the symbols loaded dont match the executable.
1) Make sure the exe you are attached to have its PDB's in the same directory and its the same version
2) make sure your source code is the same version as well
3) when debugging , open the modules window (debug --> windows-->modules). Choose load symbols and choose your pdb
If your unsure on what to do, then rebuild everything and run
oooops . i didnt read your post properly, i assumed your using visual studio. Anyway, if your not , just find where in your IDE you need to set the symbols and check there.
Another issue is that the breakpoint is that it may be set to a blank line.
Sometimes if I have another instance of Visual Studio open as well as the one I'm trying to debug with, it plays up, especially if I've been debugging in that other one.
I'm working in VS 2008 and have three projects in one solution. I'm debugging by attaching to a .net process invoked by a third party app (SalesLogix, a CRM app).
Once it has attached to the process and I attempt to set a breakpoint in one of the projects, it doesn't set a breakpoint in that file. It actually switches the current tab to another file in another project and sets a breakpoint in that document. If the file isn't open, it even goes so far as to open it for me. I can't explain this. I've got no clue. Anyone seen such odd behavior? I wouldn't believe it if I wasn't seeing it myself.
A little more info: if I set a breakpoint before attaching, it shows the "red dot" and says no symbols loaded...no problem...I expect that. When I attach and invoke my .net code from SalesLogix and switch back to VS, my breakpoint is completely gone (not even a warning that the source doesn't match the debug file). When I attempt to manually load the debug file, then I get a message that the symbol file does not match the module. The .pdb and the .dll are timestamped the same, so I'm stumped.
Anyone have any ideas?
Thx,
Jeff
I saw this functionality in older versions of VS.Net (2003 I think). It may still exist in current versions, but I haven't encountered it. Seems that files with the same name, even in different directories confuse VS.Net, and it ends up setting a break point in a file with the same name. May only happen if the classes in the file both have the same name also. So much for namespaces I guess.
You also may want to check your build configuration to make sure that all the projects are in fact building in debug mode. I know I've been caught a couple times when the configuration got changed somehow for the solution, and some projects weren't compiling in debug mode.
Kibbee, you were right! It was two files with the same name in different folders. I was setting the breakpoint in the correct file on line 58 - it was putting the breakpoint on the other file at line 58. I was finally able to set a breakpoint by using the "Debug-->New Breakpoint-->Break at Function Name" menu option and entering my function name. It stopped exactly like it should have then.
I agree - so much for namespaces, right? Damn thing cost me a couple of hours. Oh, well...at least it's solved and I know why.
Thx for the answer and thx to Matt for his reply, too!