Controlling your debugging experience in C#
Vložit
- čas přidán 25. 07. 2024
- Check out my courses: dometrain.com
Become a Patreon and get source code access: / nickchapsas
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:
Follow me on GitHub: bit.ly/ChapsasGitHub
Follow me on Twitter: bit.ly/ChapsasTwitter
Connect on LinkedIn: bit.ly/ChapsasLinkedIn
Keep coding merch: keepcoding.shop
#csharp #dotnet
RootHidden = When you have a class that implements an IEnumerable and delegates it’s job to other enumerable, which it wraps.
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)
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!
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 🙂
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.
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.
1337 or leet
Had the same thing when he used 80085 awhile ago.
I use [DebuggerNonUserCode] in my library code, which combines DebuggerHidden and DebuggerStepThrough and can be applied to classes and structs.
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.
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.
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!
Conditional breakpoint or immediate window. Give it a try.
You can also pin properties and fields in the locals/watch window. It has the same effect as writing a DebuggerDisplay for the type with "Property1 = {Property1}, P2 = {P2}", etc. You can pin multiple prop/fields.
Immediate window. The most beneficial debugging tool ever.
I use DebuggerStepThrough on a lot of simple constructors, and DebuggerDisplay often. Makes things better.
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.
Thanks for the content
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
Pin property in "quickwatch" is very helpful. It will do the similar thing you've just shown. Unfortunately, in order to filter properties, I have to copy the "quickwatch" output with the table separation, put it to the google spreadsheet and then filter by something.
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.
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)
Very nice!
Thank you
I think you got your point across!
Alright I'll see myself out...
Are these attributes polymorphic (different views for different subclasses), or will the debugger consider only the type of the variable?
[DebuggerHidden] on a function with a "System.Diagnostics.Debugger.Break();" will break where that function is called. Useful for functions like VerifyDateFormat(string date){a without it stopping inside the checker function.
Is there an attribute to allow you to skip exceptions in certain method? I mean to prevent VS from stopping at exception and continue executing catch clause silently?
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.)
“You don’t need to debug when you don’t have bugs.” 😂
Hi bro. Is there a way to get a discount for one of your courses for someone who’s is starting with testing in Net Core?
Much love
Which visual studio extensions are you using for that debug value view?
Hi! How do you circle with red rectangle to show smth?
🔥
that sneaky 1337 @6:55
Could you make a circular reference with the DebugggerTypeProxy attribute ?
Even if you could, VS at least is smart enough to stop recursing before it runs out of stack.. Ask me how I know 😅
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!"
All these attributes are new to me, but DebuggerDisplay seems usefull, except there are no variable name validation.
Jetbrains Rider probably does since it has intellisense for it. It wouldn't be impossible to write an analyzer for it.
What program do you use to draw on the screen ? I’ve tried ZoomIt, but that zooms in, and I don’t see a way to disable the zooming.
It's ZoomIt
I've been rocking a $70 asrock board for 3 years now.
Fantastic !!
What are the operating system and the program those you use for the video man? Is that Visual Studio 2022 in a Linux distrubition?
Thanks for the video.
It's a Rider from JetBrains. I do not know the OS.
@@Adiu72 Thanks man
He is using JetBrains Rider running on Windows - but Rider runs even on MAC and Linux
@@suchoss4770 thank you so much.
@@ozgunmunar i use it At work, it's amazing
We more debugging attributes!!!
Why do you use Rider instead of Visual Studio?
Do a video on Debugger Visualizers...
How to debug library functions
I hate it when VS won't let you see into Dictionary internals like the hash table and entries
What a twist it would be to have x = 105 and x = 4, then x*y = 420
These attributes kind of break the separation of concerns
Hi nick
Hi just out of curiosity, why do you always use the numbers 69 and 420 in allllll your videos? is that a easter egg or something, hahahahahah I love your videos btw.
As a developer, I can tell you that it has to do with how the keys are arranged in the numeric pad. Those numbers are the easiest combination of digits to type. No other meaning at all, trust me.
Walmin is 100% factually correct
Yes, but it`s a pity that rider or resharper cannot fix the necessary attribytes of the object how VS does it
attributes - there, fixed it for you :)
i just output to a textfile
Instead of breakpoint on line 3 and stepping over, why don't you just put the breakpoint on line 5?
Great video, but these features are unnecessary IMO, they are OK but do we really need them?
The most useful for me is the first one by far. I've seen many people override the ToString method just to get this experience which is pretty dangerous. The rest are informational and very situational.
Perhaps they were included by the Roslyn compiler team (or similar)as I can imagine debugging those libraries may well have complex debugging scenarios that are aided by these.
Span use that because the inner value is a "pointer", using the Debugger they can show you the list of items in the span
@@nickchapsas Agree with ToString it is much easier debugging with this helper.
DebuggerBrowsable is pure evil. It's only there to annoy your colleagues
Hey Nick. You looked somewhat tired in this video. Are you taking proper rest and some time for yourself mate?
I’m very good thanks. This is a video I filmed a few months ago
Nick))) Could you talk a bit slowly. Please.
Nothing really useful mentinoned in this video.Comments have much useful suggestions.
Debuggers are evil. Don't use them. Implement excellent logging instead.
Like we used to have to add print statements everywhere before the days of debuggers… no thanks, I’ll take a debugger every time - as well as proper logging, of course.
@@portlyoldman If you have proper logging why do you need the debugger? What do you do when you have an issue reported in production? Not trying to create a argument. You do what you think is right. I think the debugger is a crutch that facilitates bad software. Not necessary in your case but quite often. I have had clients that had VS installed on there production servers.
Those are different use cases, you use debuggers mostlty during development
I don’t know if you’re trolling or not 😂
@@nickchapsas - it all lads tithe fun though, doesn't it !
Freddx L has it right though. Logging is for Production and Debuggers are for dev. mostly...
Can you stop with all these shit calle programming, you cant program anything without bugs and problèms with each line of code
For performance reasons i always make a private GetDebuggerDisplay() method so the method evaluator doesn't have to evaluate multiple properties, only the one call in [DebuggerDisplay("GetDebuggerDisplay(),nq")] the method gets optimized away in Release by the compiler