Sayid Hashimi here. We're going to talk today about how you can improve your debugging experience in Visual Studio for Mac. So we've got a good amount of content to cover, so let's just get right into it. So I'm going to start off with some features which we've recently enabled for .NET Core projects in Visual Studio for Mac. We can see here I've got an ASP.NET Core solution loaded here. It consists of four different projects. I haven't set any breakpoints yet. Let me go ahead and start debugging this application, and then after it gets started, we'll set some breakpoints. All right. So now we can see that the website has come up, and it also launched a browser for a API project that I have as a part of this solution. So first what I want to do is I want to go and set a breakpoint, and then we'll start exploring the different features that we have. Okay. So I've set a breakpoint here inside the create from template function here, and this is a method that I know is going to get hit as the default page loads up. So let me go ahead and refresh this page. All right. So now we can see that the breakpoint has been hit. So now we're on line 84, so let's explore some features which have recently been added here. So one of them is called run to cursor. So let's imagine you've got your breakpoint here, and you're not really interested in stepping through this double for each loop. But what you want to do is you want to inspect the result object after that's done. So what you can do is you can right-click in your code and then say run to cursor. So what that will do is it will execute the code that follows, and then when the control reaches that particular part of your code, the debugger will then pause your application, and then you can use the debugger features as you normally would. All right. So now there's also a very similar, but different functionality that we have as well, that we've recently added. So let's say you've been debugging this application, and you're currently at line 97. But what you want to do is you really want to go back to line 84 and then step into create from text. So what you can do is you can right-click, and then say set next statement. So I've just invoked that, and now we can see the debugger is now on line 84. This might seem like it's similar to run to cursor, but it's very different. Run to cursor will continue execution of your application, and then when it reaches the desired line, it will pause. Set next statement literally sets the next statement to wherever you've indicated, and there's no code that's being executed in between those two points. So now we can see I can then step into the create from text file and then do whatever debugger operations that I was interested in doing there. All right. So now let's say you've been debugging your app and you've then explored various different parts of the code, and now you want to go back to where the debugger has stopped. So you can easily do that with the run menu here. So in run, you can go down to show current execution line, so let me invoke that. Then we can see that it's brought us back to the create from text method here, and that's where we were kind of paused previously. All right. So now let's move on to some more kind of general debugger features which have been supported in the product for a long time. So I'm going to open a new, I'm going to open a different file here and set a new breakpoint. Okay. So this is the on get method. This is a part of the website that we recently saw. So let me continue the debugger, and then I'll go back to the browser and do a refresh. So that way we can hit that. Let's ignore this error for now. That was probably related to my set next statement. All right. Let me turn off this breakpoint and then continue. All right. We can see that we're back to the breakpoint that we've just set up here. If I was to hover over this template packs and expand it, we can see the value of that. Okay. So I've expanded that list and it's about, it's like 235 items here. You can see that the default display here is not really telling me much about the template pack, which is being displayed here. What I would like to do is try to modify the code to where I can have a more descriptive string here instead of just the standard two string. So let me go ahead and stop debugging here, and the object I want to modify is this template pack. So I'll say go to declaration, and the way that you can do this, you can add an attribute to your code, and that's system diagnostics debugger display. I'm using it in a very basic way here. So all I'm saying is to display the value for the package property. We can see that property is defined down here. That's the name of the NuGet package that the template is contained in. All right. So let me go ahead and save that, and then we'll start debugging one more time and wait for that breakpoint to get hit. All right. Now we can see the breakpoint has been hit. Let's go ahead and hover over template packs one more time and then inspect it. Okay. So instead of getting the same string repeated 235 times, now I can go in and I can actually go through and find the item that I want to inspect here. So let's take a look at Mads Christensen he's got some templates that he's created for.NET Nu, and then we can go through and then inspect those objects as well if we needed to. All right. So I showed you on hover that the debugger display attribute, then we'll show up for on hover, but we can also get that forward to go into locals and watch window. So let me go into the locals window here, and then under this, let's find template packs. Okay. I'll drill into template packs. All right. So we can see those same strings do appear in the locals and that would also appear in the watch window as well. This is not limited to Visual Studio for Mac. Visual Studio on Windows has had this similar support for as long as I can remember as well. So yeah. I believe that the Visual Studio team has recently put out a blog about more information for debugger display attribute. All right. So I'm going to go ahead and stop debugging here and then. Actually, I'm going to let it continue debugging. What I want to do now is, let's say in your code, let's say you're running into a situation where there's an exception being thrown somewhere, but you're not sure where it's at, and you're not really sure where to set the breakpoint. So what you can do is going to run and then new breakpoint, and then we can say, you want to stop, let's say when any exception has been thrown. So I went into the create a breakpoint, I selected when an exception is thrown, and then I'll pick a system.exception, and then make sure that include subclasses is also checked. So I'll say go ahead and create that breakpoint. I'm going to go back to the website and perform an operation that I know that is likely to throw an exception. You go ahead and continue. All right. I'm going to drill into a template pack, and then I'm going to change the URL to something that doesn't exist. So I just made like a little change there. So now this should raise an exception in the code. Right. There we go. All right. So now I've got a null reference exception that's being thrown on line five. What we want to do now is we could either do on hover here to inspect this. In this case, it looks like the model value is fine, but template pack looks like it's probably null. But one thing we can leverage here, if you didn't want to use the on hover, you could always go into the expression evaluator, and I got to that with the run menu. So I can say model, and I can do enter to evaluate. Let's see what's model.template pack. Yes. Model.template pack is null, and we can see that's when the exception is being raised because I've got model.template pack.icon URL. So probably should fix up my code to where it's not going to throw that null reference exception anymore. All right. So those are all the debugging tips I have for you today for .NET Core Developers and Visual Studio for Mac. One additional tip I have is to check out the docs which are available at aka.ms.vsmackdocs. Thank you very much.