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 🙂
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!
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.
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.
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
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)
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.
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.
[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.
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.)
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.
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?
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!"
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
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
RootHidden = When you have a class that implements an IEnumerable and delegates it’s job to other enumerable, which it wraps.
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 🙂
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!
I use [DebuggerNonUserCode] in my library code, which combines DebuggerHidden and DebuggerStepThrough and can be applied to classes and structs.
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.
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 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.
Immediate window. The most beneficial debugging tool ever.
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’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.
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)
I use DebuggerStepThrough on a lot of simple constructors, and DebuggerDisplay often. Makes things better.
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.
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.
[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.
I think you got your point across!
Alright I'll see myself out...
“You don’t need to debug when you don’t have bugs.” 😂
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.)
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 😅
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.
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.
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?
Which visual studio extensions are you using for that debug value view?
Are these attributes polymorphic (different views for different subclasses), or will the debugger consider only the type of the variable?
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
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!"
Hi! How do you circle with red rectangle to show smth?
Thanks for the content
I've been rocking a $70 asrock board for 3 years now.
I hate it when VS won't let you see into Dictionary internals like the hash table and entries
Why do you use Rider instead of Visual Studio?
How to debug library functions
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
that sneaky 1337 @6:55
Do a video on Debugger Visualizers...
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 :)
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
What a twist it would be to have x = 105 and x = 4, then x*y = 420
Thank you
Very nice!
Instead of breakpoint on line 3 and stepping over, why don't you just put the breakpoint on line 5?
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
We more debugging attributes!!!
🔥
DebuggerBrowsable is pure evil. It's only there to annoy your colleagues
i just output to a textfile
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.
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
Hi nick
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