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 🙂
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!
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.
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.
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
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.
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.
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.
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)
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.
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!"
[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?
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.
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.)
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.
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.
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.
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.
@@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...
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
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 🙂
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.
I use [DebuggerNonUserCode] in my library code, which combines DebuggerHidden and DebuggerStepThrough and can be applied to classes and structs.
Immediate window. The most beneficial debugging tool ever.
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.
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
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.
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 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.
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.
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)
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.
I think you got your point across!
Alright I'll see myself out...
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!"
[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.
“You don’t need to debug when you don’t have bugs.” 😂
Are these attributes polymorphic (different views for different subclasses), or will the debugger consider only the type of the variable?
that sneaky 1337 @6:55
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?
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.
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 😅
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.)
Which visual studio extensions are you using for that debug value view?
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
Thank you
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.
Thanks for the content
Hi! How do you circle with red rectangle to show smth?
I've been rocking a $70 asrock board for 3 years now.
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
Very nice!
Why do you use Rider instead of Visual Studio?
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
Do a video on Debugger Visualizers...
I hate it when VS won't let you see into Dictionary internals like the hash table and entries
How to debug library functions
🔥
These attributes kind of break the separation of concerns
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 :)
We more debugging attributes!!!
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
What a twist it would be to have x = 105 and x = 4, then x*y = 420
Instead of breakpoint on line 3 and stepping over, why don't you just put the breakpoint on line 5?
DebuggerBrowsable is pure evil. It's only there to annoy your colleagues
Hi nick
i just output to a textfile
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
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.
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
Fantastic !!
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