Controlling your debugging experience in C#

Hello everybody I'm Nick and in this video I will show you how you can customize your debugging experience in C# by using a set of attributes, called the Debugger attributes. Such attributes allow you to change the behavior of the debugger and not only make it easier for you to debug your code easier but also gives you control on how your code consumers also get to debug it.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[gdargdar]

RootHidden = When you have a class that implements an IEnumerable and delegates it’s job to other enumerable, which it wraps.

[ronsijm]

Since you mentioned debugger step through is niche - One thing I used it for is when you create a castle dynamicproxy, and apply interceptors to the object. Otherwise when you try to step into your object methods, it would always jump into the interceptors first, so I `DebuggerStepThough` the interceptors - So it looks like you're directly stepping into the methods (as expected)

[oscareriksson]

In VS debugger and in remedybg, I use the watch window a lot, it gives a little better over view if you need to see many variables interact and change values. In the watch window you can also write some code like calling trivial methods or functions or operators. But I think these annotations can be used in combination in a nice way too, or if you dont have watch windows then they seem great!

[MrGTFOplz]

I've recently been debugging something using lists of largish objects and I've only been interested in one single property. Was becoming painful expanding it everytime. Cheers!

[shokdiesel]

Immediate window. The most beneficial debugging tool ever.

[phizc]

You can also add the DebuggerDisplayAttribute as an assembly attribute. If you *really* hate yourself and your coworkers you can do for example this:

using System.Diagnostics;
[assembly: DebuggerDisplay( "420", Target = typeof(int), Type="Something..dunno..")]

int x = 69;
int y = 80085;
int z = 1337;

If you hover over one of the ints or look at them in locals or a watch window, it'll say the value is 420. And since it's an assembly attribute, it'll do that for every single int in your project. Happily it doesn't seem to be a way to "inherit" the attributes, so there's that. (until somebody sneaks a code generator into a nuget package to terminate their trustworthiness forever)

Of course this can be used for good too. If a BCL type or type from a package has a poor debugging experience, you can fix it yourself. Visual Studio has a bunch of assembly level DDAs in a file called "autoexp" (cs file, but can't type it or YT will think it's a link). The filename is also a terrific search term on Google or whatever 🙂

[sasukesarutobi]

Good debugging tips always pay dividends, especially when it comes to tweaks in setup and annotation so I'll definitely have to have a play around with these in my toy projects. Ever since I found that you could debug individual unit tests in VS2019/2022 (which was a massive boon to my workflow), I've been a convert to the benefits of debugger tricks.

[jamesbennett]

I’m so used to Nick’s constants being some variant of 69 or 420, that seeing 13 and 37 makes me wonder what I’m missing.

[protox]

I use [DebuggerNonUserCode] in my library code, which combines DebuggerHidden and DebuggerStepThrough and can be applied to classes and structs.

[narayan]

Make it easier: you can expand object props and press on the icon next to property. It will turn to flag and will be displayed like with [DebuggerDisplay] attribute. Visual Studio has something like this also if I remember correctly

[LordSuprachris]

I remember using the proxy types at several places in a former job where I had to debug through some very complex types, with loads of properties, sub-arrays of objects, etc., with only a couple of useful ones. It was way much clearer to only see what I needed while debugging than browsing through a complex tree.
And for DebuggerStepThrough, I use it on small easy to understand extension methods that I know how they work and don't want to pass through them while debugging because it's most of time irrelevant.

[klocugh]

RootHidden sounds super useful for classes implementing IEnumerable to collapse inner collection.
Proxy seems useful for debugging classes, for which you don't have source to access.

[JustinMinnaar]

I use DebuggerStepThrough on a lot of simple constructors, and DebuggerDisplay often. Makes things better.

[harag]

Great video, thanks. I use the DebuggerStepThrough when I'm debugging a winforms app, I mainly put it on events that fire, like mouse_move, or form_refresh. Though I tend to not leave it there, just add it in when I'm debuiging.

[CharlesBurnsPrime]

The video title sounded uninteresting, but I watch all of your non-AWS videos. It ended up being interesting, empowering, and at one point I laughed out loud. "Why would you want to do this...? I don't know, but you can!"

[ronsijm]

Note on DebuggerBrowsableAttribute that is also has a side effect that hidden things won't show up in intellisense anymore (though might depend on the IDE I guess)

[mabakay]

DebuggerStepThrough very useful in libraries that manage your code. For example, like Promise when using multiple Then and passing lambdas. Stepping through your code using F11 is much more convenient.

[hollow_ego]

I think you got your point across!

Alright I'll see myself out...

[FunWithBits]

[DebuggerHidden] on a function with a will break where that function is called. Useful for functions like VerifyDateFormat(string date){a without it stopping inside the checker function.

[mrx]

I wish there was a way to apply these to a class, that you can't edit yourself(external dll or whatever). Would be really nice to be able to make stuff I care about appear at the top of the properties list. Instead of having to search the name. (specifically for unity monobehavoirs, since they have A LOT of fields/props.)