Review this class's debugging attributes. How do DebuggerDisplay, DebuggerBrowsable, DebuggerTypeProxy and DebuggerStepThrough help, and what would you change?

1. Metadata the debugger reads

These attributes are compiled into the assembly as metadata. Nothing in your program reads them at run time; only a debugger does.

 Customer.cs
   [DebuggerDisplay("{DebuggerDisplay,nq}")]
   [DebuggerTypeProxy(typeof(CustomerDebugView))]
        |
        v  compiled into Portal.Domain.dll metadata
        |
  no debugger attached --> ignored completely, zero runtime cost
        |
  debugger attached, you hover a Customer
        v
  debugger reads the attributes
  --> evaluates the display expression IN your paused process
      (function evaluation: same rules and risks as the Watch window)
  --> shows "Customer 42 (Active, 3 audit entries)"

The last step is the important one: the display text costs nothing in production, but it runs your code every time a developer hovers, steps or expands a Watch.

2. Every attribute and when to use it

Visual Studio, Rider and VS Code with C# Dev Kit all honour DebuggerDisplay, DebuggerBrowsable and DebuggerTypeProxy. Support for the rarer attributes varies.

3. DebuggerDisplay syntax

[DebuggerDisplay("Order {Number,nq} total={Total}", Name = "{Number,nq}", Type = "Order")]

Because the string isn't compiled, a renamed property silently breaks the display, and a typo shows an error only when someone hovers. That is why the usual pattern is:

[DebuggerDisplay("{DebuggerDisplay,nq}")]
public sealed class Customer
{
    private string DebuggerDisplay => $"Customer {Id} ({Status})";
}

The private property is compiled, refactor-safe and testable, and the attribute string never changes.

4. What a good display expression looks like

An expensive display slows every step for everyone on the team, and a side-effecting one changes the program they are debugging.

5. DebuggerTypeProxy in practice

[DebuggerTypeProxy(typeof(OrderBookDebugView))]
public sealed class OrderBook { /* complex internal structure */ }

internal sealed class OrderBookDebugView(OrderBook book)
{
    public int Count => book.Count;

    [DebuggerBrowsable(DebuggerBrowsableState.RootHidden)]
    public Order[] Items => book.ToArray();
}

The proxy's constructor takes the real object, and its public members become the expanded view. The original fields are still available under Raw View, or with the , raw format specifier. The BCL uses this pattern for List<T>, Dictionary<TKey, TValue> and many other collections.

6. Step-through attributes and their risk

 you press F11 on: var price = Guard.NotNegative(ApplyDiscount(amount));

 [DebuggerStepThrough] Guard.NotNegative  --> skipped (good: trivial)
 [DebuggerStepThrough] ApplyDiscount      --> skipped (bad: the bug is in here)

Put them only on code that is trivially correct. On real logic they create bugs that nobody can step into. [DebuggerHidden] is stronger: breakpoints inside are ignored too, so use it even more sparingly.

7. Getters must be cheap, for everyone

The debugger isn't the only thing that reads properties:

A getter that does I/O or changes state is called at surprising times by all of them. Make expensive or effectful operations explicit methods, preferably async, such as GetOrdersAsync(cancellationToken).

8. Privacy

Debug views leak through screen sharing, recordings of pairing sessions, screenshots in tickets and conversations with contractors. The Australian Privacy Principles cover accidental disclosure as well as deliberate disclosure. Keep personal information, tokens and secrets out of DebuggerDisplay and ToString(), and hide sensitive members with [DebuggerBrowsable(Never)]. Hiding a member doesn't make it secret (it is still in memory and in Raw View), but it stops it appearing in casual views.

9. .NET 11 awareness

These attributes have been stable for many releases. .NET 9 added [DebuggerDisableUserUnhandledExceptions] for framework code that catches exceptions thrown by user callbacks; check the .NET 11 release notes for any further additions.

10. Try it yourself

1. Paste the "before" class into a console app with a fake repository and hover over an instance.
2. Put a breakpoint inside LoadOrderCount and watch it hit when you hover.
3. Apply the "after" version and compare the Watch window.
4. Rename IsActive without updating a hard-coded DebuggerDisplay("{IsActive}") string and see the display break, then compare with the private property pattern.
5. Add a DebuggerTypeProxy that shows only a summary of the audit trail, and find the original fields under Raw View.
6. Put [DebuggerStepThrough] on ApplyDiscount, set a breakpoint inside it, and see that Step Into skips it but the breakpoint still hits.

The class under review (do not copy):

using System.Diagnostics;

namespace Portal.Domain;

public interface IOrderRepository
{
    int CountOrders(int customerId);
    IReadOnlyList<string> LoadOrders(int customerId);
}

[DebuggerDisplay("{Email} {PasswordHash} orders={LoadOrderCount()}")]
public class Customer
{
    private readonly IOrderRepository _orders;
    private readonly List<string> _auditTrail = [];

    public Customer(int id, string email, string passwordHash, IOrderRepository orders)
    {
        Debugger.Launch();
        Id = id;
        Email = email;
        PasswordHash = passwordHash;
        _orders = orders;
    }

    public int Id { get; }
    public string Email { get; }
    public string PasswordHash { get; }
    public bool IsActive { get; private set; } = true;

    public IReadOnlyList<string> Orders => _orders.LoadOrders(Id); // database call in a getter

    public int LoadOrderCount() => _orders.CountOrders(Id);

    [DebuggerStepThrough]
    public decimal ApplyDiscount(decimal amount) =>
        IsActive && amount > 500m ? Math.Round(amount * 0.95m, 2) : amount;
}

The reviewed version:

using System.Diagnostics;

namespace Portal.Domain;

public interface IOrderRepository
{
    Task<IReadOnlyList<string>> LoadOrdersAsync(int customerId, CancellationToken cancellationToken);
}

[DebuggerDisplay("{DebuggerDisplay,nq}")]
public sealed class Customer(int id, string email, string passwordHash)
{
    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    private readonly List<string> _auditTrail = [];

    public int Id { get; } = id;

    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    public string Email { get; } = email;

    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    public string PasswordHash { get; } = passwordHash;

    public bool IsActive { get; private set; } = true;

    public int AuditEntryCount => _auditTrail.Count;

    // Explicit, async, and never called by the debugger.
    public Task<IReadOnlyList<string>> GetOrdersAsync(IOrderRepository orders, CancellationToken cancellationToken) =>
        orders.LoadOrdersAsync(Id, cancellationToken);

    public decimal ApplyDiscount(decimal amount) =>
        IsActive && amount > 500m ? Math.Round(amount * 0.95m, 2) : amount;

    // Cheap, side-effect free, and contains no personal data.
    private string DebuggerDisplay => $"Customer {Id} ({(IsActive ? "Active" : "Inactive")}, {AuditEntryCount} audit entries)";
}