DubuggerHidden attribute tells the Visual Studio debugger that the method is hidden from the debugging process and while debugging. This is quite helpful when you don’t want to go to stepping inside of a method while debugging.
When you mark a method with DebuggerHidden() attributes, It’s explicitly tells the debugger not to step inside of that methods and no break point will be hit over that method. Now I am going to explain the same using a Example with Intellitrace debugging.
Let’s consider you have below code snippet
We have set two break points in each of the method ( Line 22, and Line 31 as shown ) . Now if you run this application and check the output intellitrace debugging window , you will get bellow out put
As per the above image, you can see the flow of the application from Main() > Method1() > Method2() . If you also check the current live event’s “Call Stack” , that also represent the call of method2() from method1(). This is as per our expected behavior.
Now, If you don’t need to go inside Method1() while debugging and debugger should not stop inside method1() for any of the breakpoint, you have to add “DebuggerHidden()” attributes with the method1(). If you try to debug the application with the same breakpoint, CallStack() and IntelliTrace debugger view will be something different.
If you check the above image, debugger reached to Method2() through Method1(), but breakpoint in method1() never hits, because of the “DebugerHidden” attribute.
If you move from “EventView” mode to “CallView” mode in Intellitrace window, you can find the actual flow of sequence of the program.
Summary : In this blog post I have explained how we can hide a methods from debugger to step in using “DebuggeHidden” attribute.
Hope this will help you.
My Other’s Articles on Debugging :
Few Tips on Customizing Debugging Window View in Visual Studio
Mastering in Debugging in Visual Studio 2010
Interesting article. You could have also mentioned the DebuggerStepThrough attribute (http://msdn.microsoft.com/en-us/library/system.diagnostics.debuggerstepthroughattribute.aspx) which I find more useful because it disables stepping into the method, but if you do set a breakpoint in the method itself (say that you do need to evaluate if the method is behaving as expected) it will stop there.
Sure, I will try to post another blogpost on the same. Thanks again !