There are some debugger-oriented attributes in .NET, however 70% of developers don't even know that they exist and 95% of them have no idea what they do and how to use it. Today we'll try to shed light on what those attributes do and how to achieve the best of using it.
First of all, let’s define what we want to get from the debugger in VS:
Term | What it actually does |
Step Into | Steps into immediate child (that is what F11 does for standard VS layout) |
Step Over | Skips to any depth (that is what F10 does) |
Step Deeper | Steps into bypassing code, using certain attribute |
Run Through | Steps into, but only one level. All lower levels will be Stepped Over |
Now, when we have our set of terms, we can learn what JMC means. It is not a famous whisky brand or another car company. It Just My Code option, checked in or out in “Option” dialog inside Visual Studio:
The next turn is for attributes, there are four (I know about) attributes, related to debugger and used by me for efficient programming: DebuggerHidden, DebuggerNonUserCode, DebuggerStepThrough and DebuggerStepperBoundary. We will use only three first. DebuggerStepperBoundary
is the most secret attribute, which is related to debugging only in multithreaded environment. It used to avoid delusive effect, which might appear when a context switch is made on a thread within DebuggerNonUserCode
applied. In other words, when you need to Step Through in Thread A and keep running at the same time in Thread B.
So let’s see the effects occurred when using those debugger attributes in case you are trying to Step Into place, this attribute is applied or set a Breakpoint there. When Just My Code (JMC) is checked, all those attribute behaviors are the same – they Step Deeper. However, when JMC is turned off (as in my picture), they begin to behave differently.
Attribute | Step Into | Breakpoint |
DebuggerHidden | Step Deeper | Step Deeper |
DebuggerNonUserCode | Step Into | Step Into |
DebuggerStepThrough | Step Deeper | Step Into |
As you can see, in this case:
DebuggerNonUserCode
respects both for F11 (Step Into) and Breakpoints DebuggerStepThrough
respects only for Breakpoints DebuggerHidden
does not respect at all – just like when JMC is checked.
Bottom line: If you want people to manage whether or not to enter into your hidden methods – use DebuggerNonUserCode
attribute. If you prefer them not to even know that those methods exists, use Deb
uggerHidden. If you want them to be able to put Breakpoints and stop on them, but keep running without explicit action – use DebuggerStepThrough
.
Have a nice day and be good people. Happy friendly debugging to other developers.
Small bonus: To visualize your struct, class, delegate, enum, field, property or even assembly for user debugger, you can use DebuggerDisplay attribute (you need to put executable code into {}
for example (“Value = {X}:{Y}
”)]
Thanks to Boris for deep investigation.