Tamir Khason – Just code

Visual Studio debugger related attributes cheat sheet

There are some debugger-oriented attributes in .Net, however 70% of developers not even know that they exist and 95% of them has no idea what they doing and how to use it. Today we’ll try to lid light on what those attributes doing and how to achieve the best of using it.

First of all let’s define what we want to get from 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 lavels will be Stepped Over

Now, when we have our set of terms, we can learn what JMC means. It is not famous whisky brand or another car company. It Just My Code option, checked in or out in “Option” dialog inside Visual Studio

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, might appears when a context switch is made on a thread within DebuggerNonUserCode applied. 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 applied or set a Breakpoint there. When Just My Code (JMC) is checked all those attributes behaviors the same – they Step Deeper. However, when JMC is turned off (as in my picture) they begin to behavior 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 respects at all – just like when JMC is checked.

Bottom line: if you want people to manage whether to enter or not 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 other developers friendly debugging.

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

You may also be interested with:

1. Nifty time savers for WPF development
2. INotifyPropertyChanged auto wiring or how to get rid of redundant code
3. Quick how to: Reduce number of colors programmatically
4. Capturing and streaming sound by using DirectSound with C#
5. Making TFS better or what is TITS?

April 7th, 2009 · Comments (6)