I've created a DLL with a Class Library Project with some classes. While adding this DLL as a reference in another projects and debugging, when going step by step or when the class returns an Exception the code from the class is shown.
How can I hide this? I want the exception to be shown on the class instruction, not inside and allowing to see al the code. And when debugging by steps, I want to do the methods without steping inside the code of the method.
Just like if you step through str.Split(), for example. You don't see the code and all the steps. You just see the error on that line or jumps to the next one.
For example:
Dim myObj As New myClass.SomeObj()
myObj.MyMethod()
I do not want the code inside MyMethod to be shown.
Add on the specified method a DebuggerStepThrough attribute to prevent step into. If an exception occures, the debugger breaks at the method call, not inside the method. See MSDN
The behavior you describe is a convenience. It allows the caller to see exactly what is going wrong by looking at the details of the code he's trying to consume. Microsoft even supports this for the .NET Framework source, and it's rather useful in my opinion. I'm not really sure why you'd want to disable it. You can always just use F10 (Step Over) instead of F11 (Step Into) when debugging so that the DLL's code remains available in case you ever need it.
But if you are sure that you don't want to be able to step into any code from the DLL, you need to make sure that the debug symbols are not available to the client application. Visual Studio generates these symbols in the form of a PDB file, which contains the location of the source files and mappings between the generated code and the source lines.
Contrary to some of the other answers, the generation of debug symbols is unrelated to whether the code is optimized (e.g., a "Release" build). I've written about this before in the context of why you might want symbols for an optimized build, but the point is that these are two orthogonal settings. You can turn on optimization and turn off symbol generation, and vice versa. Suffice it to say that I strongly recommend generating debug symbols for all builds.
You can disable the generation of debug symbols in the project's properties (it's hidden under the "Advanced..." button), or you can just move the PDB files to ensure that the client application cannot locate them when debugging. By default, a build places them into the same directory as the binary output, so that when you add a reference to the DLL, Visual Studio finds them easily. If you move either the symbols or the binaries, it won't be able to find them. (The debugger also searches the symbol path, but your symbols probably won't end up there.)
Related
We are building a solution for Release, but when attempting to attach using studio 2010 professional, no thread is showing any stack information, nor any breakpoint can be set, etc.
The goal is to be able to attach the Visual Studio/JIT Debugger to the running process while having as many optimization benefits as possible.
Most of our searches comes down to 'compile with debug:full' and you will be able to debug, but that doesn't seem to be the case, I thing that the JIT optimizes the code in runtime and thus we cannot debug, is this true?
Is it possible to compile and tell the JIT to downplay the optimizations and allow debugging? (while retaining other optimizations)
UPDATE
using #HansPassant's answer, I looked at the modules and saw that although the pdbs are in the same directory as the binaries, indeed no debug symbols were loaded. what I also saw is that the my libraries are marked as 'User Code'-'NO' which is probably the reason it was not loaded automatically.
By loading symbols manually AND disabling 'just-my-code' I was also able to set breakpoints and see stacks.
Question now: why is my code not marked as User Code? is this normal behavior? can I configure this to my assemblies in some way to avoid this?
Debugging optimized code is no great pleasure. You certainly may have trouble setting breakpoints, a method may have been inlined. And inspecting local variables and method arguments is liable to make the debugger sulky when the variable was optimized to be stored in a cpu register.
You however certainly can still inspect call stacks, you'll see the methods that didn't get inlined in the stack trace. Basic mistakes you might make:
when you attach a debugger, you get the option to select the debugger type. Be sure to select "Managed", you will not have much use for the native debugger
be sure that you are looking at the correct thread, the program can be broken at an arbitrary location. Use Debug + Windows + Threads to select the appropriate thread
be sure that you are actually broken at a location in your code. You can easily end up inside a Windows operating system DLL or a framework method, there will be very little to look at when that's the case. Tools + Options, Debugging, Symbols and enable the symbol server so that stack traces that start inside Windows will be accurate
the debugger must be able to locate the PDB files. Use Debug + Windows + Modules, you'll see the assemblies loaded in the process. First make sure that the one you want to debug is actually loaded. Right-click it and select "Symbol load information". It shows you where it looked for the PDB file
the "just my code" option can get in the way heavily, you are very likely to run into significant chunks of code that are not yours. Tools + Options, Debugging, General and turn that option off.
Thought I'd follow up with an additional answer regarding your updated question to help others.
From Microsoft:
To distinguish user code from non-user code, Just My Code looks at symbol (.pdb) files and program optimizations. The debugger considers code to be non-user code when the binary is optimized or when the .pdb file is not available.
In my application i am using the third party dll and i dont have any soruce code avialable.
Now i am getting the exception in Windows7 OS, so i would like to debug and kwow what is the exact reason.
Reflector will not help me in this case as its a unmanaged dll. And decompiler is giving error on passing this dll(Extraction of source code).
To debug in visual studio, it expects the PDB file and .pdb can be generated only from source code.
In the debug section i slected "Enable Native code debugging option" and in security section i selected the option as paritially trusted application to get rid of the exception.
I am not able to conclude, what could be the problem and dont have any idea apart from above, how to resolve?
On my knowlege we can not debug unmanaged dll, if we dont have source code available.
Can any one please suggest, if we have any techniques around that.
My thought process: If i can get runtime information on which API its failing, i could opt for alternative API and resolve the problem.
Thanks in advance.
Regards,
Siva.
Of course you can debug it. You can step through assembly code just fine and check the state of registers, etc.
It seems that you really want to debug by inspecting and executing the original source code. This is obviously impossible without the source code, as it is in general not possible to reverse engineer the source code from optimized native executable (it is possible to reverse engineer functionally equivalent code, but this can differ heavily from the original source). Native dll usually doesn't contain names of the symbols (classes, functions, members, etc) except for the exported ones, so it is not possible to create e.g. a friendly stack trace with method names.
Besides that, even if you had source code, it would be useless without symbol file (.pdb), as pdb contains data about mapping between original source code and compiled instructions, as well as other information (symbol names, optimization info, etc).
However, it is not that hard to debug using assembly code if you have a pdb file but not the source code (ok, it is not that easy, either :). These 2 articles (http://www.microsoft.com/msj/0298/hood0298.aspx and http://www.microsoft.com/msj/0698/hood0698.aspx) have enough info to debug most of the usual situations where you might need that.
I'm trying to re-jig the layout of a very large solution which has become impossibly hard (and s l o w) to work with. My plan is to create a number of solutions containing related projects, and then use binary references where necessary to link to libraries produced by the other solutions.
The thing we rely on to make this usable is Resharper's Navigate to External Sources functionality, so we can easily browse the source of the projects we are referencing from other solutions. Quite why VS can't do this out of the box is beyond me.
This is all working very nicely for classes with implementation. However, for C# interfaces and classes containing only auto-implemented properties, Resharper isn't able to browse to the sources, and falls back to cruddy metadata viewer.
I used srctool.exe, which comes with the Symbol Server tools in MS Debugging Tools For Windows, to browse the sources listed in the .pdb file, and it's clear that the sources for these interfaces and empty(ish) classes are not referenced in the pdb file. If I switch the auto-implemented properties to those with backing fields, then the source link appears in the pdb.
I'm guessing the sources are excluded because there are no places you could set breakpoints on interfaces and auto-implemented properties.
I'm wondering, though, if there is some exotic compiler option or workaround we can employ to force the PDB file to include references to the source of C# interfaces.
Thanks,
Mark
The question doesn't have enough detail. Shooting off the hip, I'd guess that you tackled the problems with the slow massive solution by converting project references to assembly references. And used the Release build of those projects as the reference.
And yes, that stumps any tool that tries to find source code files from the PDB. The release build of a .NET project uses a stripped version of the PDB, all the source code file and line number info has been removed from it. That's a pretty normal thing to do with real release builds. Release built code normally is optimized. That causes code to be re-ordered, no longer matching the logical position of the code in the source file. Any info you get from the source+line PDB info now tends to get between harmful and useless, you start looking in the wrong place for a problem.
That is however not a concern for IDE tooling or while debugging your app. The optimizer is automatically disabled in a case like this. Actually a configuration item in VS: Tools + Options, Debugging, General, "Suppress JIT optimization on module load" option. Turned on by default.
Clearly any tooling that uses the PDB is going to catatonic when they don't have a chance to find source files. The fix is to go back to the original project, select the Release configuration again and change a setting: Project + Properties, Build tab, scroll down, Advanced button. Change the "Debug info" combo from "pdb-only" to "full". Rebuild the project.
Should fix your problem. Also revives the debugger, you can step into the source code again.
Don't move files around too much btw, you might stump the chumps again. At least keep the PDB with the DLL in the same directory. If the source code is no longer present in the same directory but you checked it out again in another one then you have to tell the IDE about it. Right-click the solution, Properties, Debug Source Files setting.
My C# debugger is not working properly. It skips break points and line of codes sometimes. I have checked the configuration manager. I have even tried adding my projects to new solution files. Can someone please help me?
My debugging checklist:
Make sure your attaching to the process using the correct code type - if your process has both unmanaged and managed code then dont rely on "auto" to work for you, explicitly state what sort of code your trying to debug
Goto the modules window (Debug -> Windows -> Modules, you may need to enable it in the "Customize..." menu
Check to make sure that the assembly your trying to debug has been loaded, and that symbols have been loaded - if they haven't been loaded then right click on that module and select "load symbols"
Open your code file and place your breakpoint - if it appears with the little warning symbol then look and see what it says,
You might need to goto "tools -> options - > debugging -> general" and untick "Enable Just My Code (Managed Only)"
You might also want to uncheck "Require source files to exactly match the original version", if you think your sources might be slightly out (beware however, as this can lead to you debugging with completely the wrong sources, which can be very confusing)
On certain cases you might find that your module doesn't get loaded at the point where you attach your debugger (for example if you have some sort of plug in archetecutre, and plugin assemblies are only loaded when you first use them). In these cases all you can do is try and make sure everything is prepared ready for when the module is loaded.
Make sure optimizations are disabled (this is the defaut for the Debug configuration, but they are enabled in Release configuration). Compiler optimizations can mess with the debugger...
Are you sure that it compiled correctly? It sounds to me like you're debugging against a previous version, which can happen if the build fails (perhaps a code bug, perhaps the files are readonly).
If entire methods are being skipped, look at the source and see if the System.Diagnostics.DebuggerStepThroughAttribute attribute is present.
Despite the name, it PREVENTS the debugger from stepping through the method.
This worked for me in VS 2017, Go to Tools > Options then under the Options Window go to the Debugging section. Enable - "Enable .NET Framework source stepping"
This sounds like your source code is out of sync with the PDB files. The easiest solution is to clean the solution (which deletes all your dlls from the bin folder). Recompile, and then try stepping through again.
If it still fails, try closing the solution and deleting the "obj" folders. And then try again.
And also check you are compiling in debug mode - something I've done often ("why isn't it stepping through?!")
not getting break point
If at least sometimes the break point is hit it means that all the settings are most probably OK.
The missing hits may be caused by some side-effects, for example: property evaluation by the debugger (at least VS skips the breakpoints during the property evaluation for debugger) or some spying tools (but these are usually catch by debugger).
If you think this may be the case, turn off the spying tools and disable the property evaluation by the debugger.
This may be sometimes not enough, for example: If your property returns a collection, displaying e.g. a Count() will evaluate the property - so remove also all references of property from the watch windows, etc.
Disabling "Project Properties/Build/Optimize code" worked for me.
#Justin's answer above was super helpful. I would add one thing to the list.
Check to make sure you're running in debug and that your debug preferences have "Optimize code" unchecked. See below:
Also make sure that the code you're trying to debug is running in the same process as the main executable. I just wasted a half hour figuring that one out - the breakpoint wasn't hitting because the code of interest had been spun up in a child process instead of being called directly (the program in question has two different modes of operation).
If you're getting this kind of error:
The current .NET SDK does not support targeting .NET Core 2.1. Either target .NET Core 2.0 or lower, or use a version of the .NET SDK that supports .NET Core 2.1. DCR_Parser
Right click on the project in solution explorer and click on Properties. Under the Application tab go to Target framework .NET Core 2.0. And save.
I have a project that imports a DLL (written by me). Sometimes when an exception is raised within a method in the DLL, the host project opens a tab and let me see the code within the DLL. I can also put breakpoints within it.
But this behavior seems quite random, I cannot have it on purpose and not always works. Plus, I can't see the file name in the project explorer window.
Any help on debugging DLLs? Thanks
The enhanced debugging (for a dll not in the current solution) depends largely on whether you have the debugging symbols file (.pdb) in an obvious location - in particular, next to the dll itself. You can also load symbols manually from the modules window (when debugging, Debug -> Windows -> Module, right-click, Load Symbols From...)
What may be getting in your way here is a feature known as Just My Code (JMC). This is a debugger / CLR feature designed at limiting a users view of the world to just the code that they've written. The various ways in how a piece of code or DLL is determined to be yours or not can be confusing at times.
Next time you hit this problem, try disabling JMC and see if it fixes your problem
Navigate: Tools -> Options
Navigate: Debugger -> General
Uncheck the Just My Code option
On the managed C# program that calls the C++ dll,
right-click properties
debug tab
Tick Enable unmanaged code debugging
Hope this helps,
Tony.
To debug a dll it must have the pdb file with the debugging information that matches that dll.
Visual studio uses the .Pdb symbols generated by the compile process to enable you the dev to peek at the source when an exception occurs.
This information exists for two reasons. The first reason is for the compiler (i.e., a program that turns source code into an application, such as an .exe or .dll file) to use when it builds the application. The second reason is for people to use when debugging an application. The symbolic information is generated as part of the compilation of an application (if you set the compiler to generate symbolic information). This information can reside directly in the application files, or it can be written to separate symbol files. Where the symbols reside depends on your development application and the settings you choose. For example, Microsoft Visual Basic (VB) builds symbols right into the program files. Visual C++ (VC++) usually builds one or two separate files.
Symbol files have two file types—.dbg and .pdb. The .dbg files are in Common Object File Format (COFF), which is a generic symbol file description that doesn't include source line information; many debuggers can read these files. The .pdb files are a Microsoft format and contain a lot more information than the .dbg files. For example, source line information is available only in .pdb symbols. Symbol files that include source-code line information let you use the source code for debugging.
While it doesn't allow you to debug the code, Reflector is very useful when it comes to inspecting a DLL. The combination of a Stack Trace, the offending DLL and reflector will often get you to the nub of the problem.