DebuggerStepThrough

  • Thread starter Thread starter Clive Dixon
  • Start date Start date
C

Clive Dixon

In VS2003, you could decorate a method/property accessor with
DebuggerStepThrough, and you could put a breakpoint inside that method and
IIRC subsequently do single step F10 debugging after it had hit the
breakpoint.

In VS2005, I find that F10 acts the same as F5 - in other words, I can no
longer do single step debugging inside a method marked with
DebuggerStepThrough. Does anybody know any way in which I can make it behave
in the VS2003 manner so that I can actually debug my methods without having
to take off all the DebuggerStepThrough attributes and recompile?
 
Hello,
Does anybody know any way in which I can make it behave in the VS2003
manner so that I can actually debug my methods without having to take off
all the DebuggerStepThrough attributes and recompile?
Click to expand...

The idea of the DebuggerStepThrough attribute is that the debugger shouldn't
stop on the method, so the best solution in my opinion is to take these
attributes away. That is, why would you have the attributes, if you
sometimes want to step into the methods?

You could use the Step Over and Step Into commands to selectively go to the
methods, or skip over them. Also, it should be fairly easy to do a
Find/Replace to all the attributes: all you need is to comment them out.

Hope this helps.

--
Regards,

Mr. Jani Järvinen
C# MVP
Vantaa, Finland
(e-mail address removed)
http://www.saunalahti.fi/janij/
 
Clive said:
In VS2003, you could decorate a method/property accessor with
DebuggerStepThrough, and you could put a breakpoint inside that method and
IIRC subsequently do single step F10 debugging after it had hit the
breakpoint.

In VS2005, I find that F10 acts the same as F5 - in other words, I can no
longer do single step debugging inside a method marked with
DebuggerStepThrough.
Click to expand...

Just leave off DebuggerStepThrough. From the MSDN: "The common language
runtime attaches no semantics to this attribute. It is provided for use by
source code debuggers. For example, the Visual Studio 2005 debugger does not
stop in a method marked with this attribute but does allow a breakpoint to
be set in the method."

In other words, it seems to do the exact opposite of what you expect it
does. I don't know what it was supposed to do in VS 2003.
Does anybody know any way in which I can make it behave in the VS2003
manner so that I can actually debug my methods without having to take off
all the DebuggerStepThrough attributes and recompile?
Click to expand...
Nope. However, replacing "[DebuggerStepThrough]\n" with "" is easily done
with "Replace in Files" (Ctrl-Shift-H in the default assignment) and regular
expressions.
 
Yes, but you are still allowed to put a breakpoint inside the method - read
the documentation. If you are allowed to break inside it, you should be
allowed to single step once it has hit that breakpoint. The observed
behaviour doesn't make sense and makes the attribute totally pointless. If
you actually wanted to prevent adding breakpoints altogether within the
method you would use the DebuggerHidden attribute instead. Because you can't
single step once you have hit the breakpoint, the DebuggerStepThrough
attribute adds no real value over the DebuggerHidden attribute.

I have added DebuggerStepThrough for a reason, but I still want to be able
to set the breakpoint, as per VS documentation, and trace through the method
where necessary.
 
You've missed the point - read my response to Jani.

Nime said:
Just place [DebuggerStepThrough] before the function and set breakpoint.
You have to disable Just My Code option from Tools > Options > Debugger
You will hit the breakpoint.

http://msdn.microsoft.com/en-us/library/h5e30exc.aspx




iletide þunu yazdý said:
In VS2003, you could decorate a method/property accessor with
DebuggerStepThrough, and you could put a breakpoint inside that method
and IIRC subsequently do single step F10 debugging after it had hit the
breakpoint.

In VS2005, I find that F10 acts the same as F5 - in other words, I can no
longer do single step debugging inside a method marked with
DebuggerStepThrough. Does anybody know any way in which I can make it
behave in the VS2003 manner so that I can actually debug my methods
without having to take off all the DebuggerStepThrough attributes and
recompile?
Click to expand...
Click to expand...
 
Hello!
Yes, but you are still allowed to put a breakpoint inside the method -
read the documentation.
Click to expand...

I'm very well aware of the functionality, thank you. That's exactly the
reason I'm suggesting that you should remove the attribute from those
methods which you wish to step into. See below:
If you are allowed to break inside it, you should be allowed to single
step once it has hit that breakpoint.
Click to expand...

Yes, you could argue that the attribute would work that way, but to me, you
are asking that the debugger should not allow stepping into the method in
question, and that's precisely what Visual Studio is doing.

Now, in the future Visual Studio versions might work differently (why not
create or vote an existing suggestion on Connet?), but in the mean time you
have to work with the limit (if you will) of the debugger.

You mentioned that you are using the attribute for a reason, but haven't
told us why. This information would possibly help suggest an alternative.

Thanks!

--
Regards,

Mr. Jani Järvinen
C# MVP
Vantaa, Finland
(e-mail address removed)
http://www.saunalahti.fi/janij/
 
2465


<a href=http://www.3226.com/>3596</a>



Posted as a reply to:

DebuggerStepThrough

In VS2003, you could decorate a method/property accessor with
DebuggerStepThrough, and you could put a breakpoint inside that method and
IIRC subsequently do single step F10 debugging after it had hit the
breakpoint

In VS2005, I find that F10 acts the same as F5 - in other words, I can no
longer do single step debugging inside a method marked with
DebuggerStepThrough. Does anybody know any way in which I can make it behave
in the VS2003 manner so that I can actually debug my methods without having
to take off all the DebuggerStepThrough attributes and recompile?

EggHeadCafe - Software Developer Portal of Choice
WCF Workflow Services Using External Data Exchange
http://www.eggheadcafe.com/tutorial...a-6dafb17b6d74/wcf-workflow-services-usi.aspx
 
Back
Top