Visual Studio Debugger Related Attributes Cheat Sheet

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.

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 DebuggerHidden. 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.