You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: nanoFramework.CoreLibrary/System/Diagnostics/DebuggerAttributes.cs
+16-4Lines changed: 16 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,8 @@
4
4
// See LICENSE file in the project root for full license information.
5
5
//
6
6
7
+
usingSystem.Runtime.CompilerServices;
8
+
7
9
namespaceSystem.Diagnostics
8
10
{
9
11
usingSystem;
@@ -15,7 +17,9 @@ namespace System.Diagnostics
15
17
/// Designer provided types and members that are not part of the code specifically created by the user can complicate the debugging experience. This attribute suppresses the display of these adjunct types and members in the debugger window and automatically steps through, rather than into, designer provided code. When the debugger encounters this attribute when stepping through user code, the user experience is to not see the designer provided code and to step to the next user-supplied code statement.
16
18
/// The debugger behaviour when the <see cref="DebuggerNonUserCodeAttribute"/> is present is similar to using a combination of the <see cref="DebuggerHiddenAttribute"/> attribute, which hides the code from the debugger, and the <see cref="DebuggerStepThroughAttribute"/> attribute, which tells the debugger to step through, rather than into, the code it is applied to.
@@ -30,7 +34,9 @@ public DebuggerStepThroughAttribute() { }
30
34
/// <remarks>
31
35
/// The <see cref="DebuggerStepperBoundaryAttribute"/> attribute is used as an escape from the effect of a <see cref="DebuggerNonUserCodeAttribute"/>. When executing within the boundaries of the <see cref="DebuggerNonUserCodeAttribute"/>, designer-provided code is executed as a step-through until the next user supplied code is encountered. When context switches are made on a thread, the next user-supplied code module stepped into may not relate to the code that was in the process of being debugged. To avoid this debugging experience, use the <see cref="DebuggerStepperBoundaryAttribute"/> to escape from stepping through code to running code. For example, in Visual Studio 2005, encountering a <see cref="DebuggerStepperBoundaryAttribute"/> while stepping through code using the F10 key (or Step Over command) has the same effect as pressing the F5 key or using the Start Debugging command.
@@ -45,7 +51,9 @@ public DebuggerStepperBoundaryAttribute() { }
45
51
/// <remarks>
46
52
/// 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 and does not allow a breakpoint to be set in the method. Other debugger attributes recognized by the Visual Studio 2005 debugger are the <see cref="DebuggerNonUserCodeAttribute"/> and the <see cref="DebuggerStepThroughAttribute"/>.
@@ -61,7 +69,9 @@ public DebuggerHiddenAttribute() { }
61
69
/// Designer provided types and members that are not part of the code specifically created by the user can complicate the debugging experience. This attribute suppresses the display of these adjunct types and members in the debugger window and automatically steps through, rather than into, designer provided code. When the debugger encounters this attribute when stepping through user code, the user experience is to not see the designer provided code and to step to the next user-supplied code statement.
62
70
/// The debugger behaviour when the <see cref="DebuggerNonUserCodeAttribute"/> is present is similar to using a combination of the <see cref="DebuggerHiddenAttribute"/> attribute, which hides the code from the debugger, and the <see cref="DebuggerStepThroughAttribute"/> attribute, which tells the debugger to step through, rather than into, the code it is applied to.
0 commit comments