DebuggerStepThrough being ignored

Question

I have noticed lately that the Visual Studio 2010 debugger keeps jumping into this method that is marked with the [DebuggerStepThrough] attribute.

Answer 1

Try this simple console application, put break points on the lines indicated, run the debugger and on the first break point, press step into (F11). It should miss the second break point. Otherwsie if might be a visual studio setting/extension messing things up.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Diagnostics;

namespace tmp {
    class Program {
        static void Main(string[] args) {
            IEnumerable<Type> types = typeof(System.IO.IOException).GetHierarchy(typeof(System.Exception)); //break point here
            int i = 0;
        }
    }
    static class Ext {
        //[DebuggerStepThrough]
        //[DebuggerNonUserCode]
        //[DebuggerStepperBoundary]
        public static IEnumerable<Type> GetHierarchy(this Type type, Type limit) {
            if (type == null) { //break point here
                throw new Exception();
            }
            do {
                yield return type;
                if (type == limit) {
                    yield break;
                }
            } while ((type = type.BaseType) != null);
        }

        [DebuggerStepThrough]
        public static IEnumerable<Type> GetHierarchy2(this Type type, Type limit) {
            if (type == null) { //break point here
                throw new Exception();
            }
            IList<Type> types = new List<Type>();
            do {
                types.Add(type);
                if (type == limit) {
                    break;
                }
            } while ((type = type.BaseType) != null);
            return types;
        }
    }
}

EDIT

Actually i think it has something to do with the yield statement. If i try building a list (GetHierarchy2), i have no problem with the DebuggerStepThrough attribute

Answer 2

Are you debugging a release mode binary? It might be optimized and maybe just deterministic for the compiler at compile time so you won't be able to step in. Take a look at the IL generated and see if this is the case.