C# / .NET
LINQ
Evaluate parts of the query in QuickWatch.
Place breakpoints in the lambda expressions.
Use a log-middleware method.
More: https://michaelscodingspot.com/debug-linq-in-csharp/
Other tools
Visual Studio
Breaking on Exceptions with or without source code In Menu, go to Debug -> Windows -> Exception Settings. Toggling CLR exceptions controls whether to break on managed exceptions.
To break on exceptions from all code, go to Tools -> Options and in Debugging, uncheck “Enable Just My Code”.
Shortcuts
Debug | Attach to Process (CTRL + ALT + P)
Continue (F5)
Step Over (F10)
Step Into (F11)
Run execution to here. Stand on the desired line of code and click Ctrl + F10
Run to a cursor location. Stand on the desired line of code and click Ctrl + Shift + F10
Open QuickWatch (Shift+F9 or Ctrl+D, Q)
QuickWatch or Watch
Open QuickWatch (Shift+F9 or Ctrl+D, Q)
Open Watch from Debug | Windows | Watch | Watch 1 or Ctrl + Alt + W + 1
Holding Ctrl will make the DataTip transparent
You can add the
, nse(No Side Effects) postfix to an expression, and it will evaluate without changing the application state.
Immeadiate Window
Is available in the menu from Debug | Windows | Immediate or Ctrl + Alt + I
Locals and Autos Windows
VS offers 2 automatic-watch tool windows: The Locals and Autos windows.
The Locals will show local variables of the current scope. It usually starts with this, which represents the current class.
The Autos window will show all variables used in the current line and in the previous line. These could be local variables, class members or static variables. The Autos also shows values returned from methods, which is useful at times.
Call Stack Window
One of the most useful tool windows is the Call Stack Window. It shows the chain of methods that called one another, up to the the currently debugged method.
Note that there’s a greenish arrow on the left. This shows that this is the currently debugged method, but also that it’s not the topmost Frame. While in this mode, you can hover over variables in the current Frame (method) and see their values.
Besides the ability to switch frames by double-clicking, you can open the Call Stack’s context menu by mouse right-clicking on any frame.
Unwind To This Frame – When an exception is hit, you can "Unwind the call stack". That’s sort of like going one step back in time, before the exception happened so you can make use of a feature called Edit and Continue. This feature allows to change code live while debugging. In this way, you can theoretically change the code so as to prevent the exception from happening. We’ll talk more about exceptions in the next part of the tutorial.
Show External Code – When checked, you will see Frames from Modules that are not your own source code. This might the .NET framework itself, or from some 3rd party library you are using. Very useful feature for advanced scenarios.
Threads Window
This window shows all the currently active threads, and allow to switch between them.
You can switch between threads by double clicking the row.
To see the Call Stack of a thread, you can switch to a threads and then open the Call Stack window. Alternatively, the Threads window has a little arrow between the Name and Location column that allows you to see the call stack.
You can Search the call stack for namespaces, names of methods, thread ID, and anything else that can be seen in the columns.
DebuggerDisplay Attribute
dotTrace Performance Profiler
Sometimes, we have to work on new, unfamiliar projects. Suppose you have to fix a bug in such a new project, where you can reproduce the bug, but have no idea what happened in the code. How do you even know where to place a breakpoint and start debugging?
There are a lot of ways to go about it. You can try to find UI event handlers, guess class names according to functionality or ask someone for help. I’d like to suggest another alternative: Use a performance profiler!
dotTrace is able to attach to a process and “record” a runtime section. The recording is called a Snapshot.
Suppose I record the 10 seconds where my bug reproduces. Now, dotTrace will show a list of all the methods called during the recording.
There’s a bunch of useful information and features, much for performance profiling. In particular, you can see how much time was spent on each method. You can also view which methods were called by a specific method and the other way round – which method called the specific method.
So dotTrace is useful not just to solve performance issues. Whenever I’m working on unfamiliar territory, dotTrace will give me a picture of what happens in the code!
More to it:
Last updated
Was this helpful?