WEBVTT 00:00.170 --> 00:02.240 What we're going to take a look at in this lesson. 00:02.240 --> 00:06.350 And it's not particularly helpful to us at the moment due to the amount of code we've got, but we're 00:06.350 --> 00:11.090 going to set it up so it's available to us whenever we need to use it. 00:11.090 --> 00:12.920 And that's the dotnet debugger. 00:12.950 --> 00:15.920 Now I'm going to demonstrate this using VS code. 00:15.950 --> 00:19.130 Of course Visual Studio comes with its own debugger. 00:19.250 --> 00:21.410 Rider as well comes with its own debugger. 00:21.410 --> 00:26.060 If you're using that, I won't be able to demonstrate that I can't demonstrate everything about everything, 00:26.060 --> 00:31.280 but I can demonstrate how to set up the debugger on VS code, because there are some steps you need 00:31.280 --> 00:33.650 to take to get this to function. 00:33.650 --> 00:35.090 So we'll head back to VS code. 00:35.090 --> 00:37.340 Let's just close this stuff down. 00:37.340 --> 00:44.180 And if we go on to this tab in VS code then this is our debugging tools effectively. 00:44.210 --> 00:46.070 Now we can't do much at the moment. 00:46.070 --> 00:51.860 We need to create one of these launch.json files to actually set up the debugger in C-sharp. 00:51.860 --> 00:53.330 So I'm just going to click on this. 00:53.330 --> 00:55.850 And then we select the debugger we wish to use. 00:55.850 --> 00:59.840 Now for C-sharp code we use the C-sharp debugger of course. 00:59.840 --> 01:01.550 And this is what it gives us. 01:01.550 --> 01:07.700 It just gives us an empty file that just gives us some comments and not much else. 01:07.730 --> 01:12.350 So we need to add some configurations, but there's a helpful little button down here that says add 01:12.350 --> 01:13.400 configuration. 01:13.400 --> 01:15.410 And then we've got our different options. 01:15.440 --> 01:17.630 Now we're going to add two configurations here. 01:17.660 --> 01:24.500 My personal favorite for debugging purposes is to use this one to attach to an already running dotnet 01:24.500 --> 01:25.100 process. 01:25.100 --> 01:29.960 So typically I like to keep the API server running pretty much all the time. 01:29.960 --> 01:35.570 And if there comes a time where I feel I need to debug some code, then I'll just use this option to 01:35.600 --> 01:39.770 attach a debugger to an already existing process. 01:39.800 --> 01:44.330 We'll also add another configuration, because there are certain types of code where this will not work 01:44.330 --> 01:48.800 for us, and for certain types of code, that system will not work for us. 01:48.830 --> 01:54.560 Is the program class because we can only attach a debugger after we've got to this stage in our code, 01:54.560 --> 01:56.690 and we're actually running our application. 01:56.690 --> 02:03.260 If we wanted to debug something going on inside the DB initializer, Then we would have to use a different 02:03.260 --> 02:09.350 approach, and the different approach we'd take is we'd have to launch the C-sharp project with the 02:09.350 --> 02:10.880 debugger attached already. 02:10.880 --> 02:13.340 So that's the other one we'll set here. 02:13.340 --> 02:15.470 But this one needs a bit of configuration. 02:15.470 --> 02:19.880 So I'm just going to say API debug as the name of the thing. 02:19.880 --> 02:26.540 And then we need the relative path to the project folder which should be API csproj. 02:26.540 --> 02:27.890 But we'll test that. 02:27.890 --> 02:29.630 That's what it should be for this. 02:29.630 --> 02:34.040 And the dotnet core attached, we don't need to add any additional configuration. 02:34.040 --> 02:36.470 So I have the API server running. 02:36.470 --> 02:43.460 So the first one we'll check or test is the attach the debugger option. 02:43.460 --> 02:47.630 So let's go to our files in Solution Explorer. 02:47.630 --> 02:51.080 And like I said we don't have a huge amount of code to look at at the moment. 02:51.080 --> 02:57.800 And if I go to the products controller, then let's take a look at the getting of an individual product 02:57.800 --> 02:59.000 and I'll just add a breakpoint. 02:59.000 --> 03:05.550 We just click on the left hand side of the line numbers to get that red dots applied there. 03:05.550 --> 03:12.000 Then we go back to our debugging tab, and then we choose which option we wish to use for the debugger. 03:12.000 --> 03:13.320 So we've got our two options there. 03:13.350 --> 03:16.290 We've got API debug that's going to launch the process. 03:16.290 --> 03:21.540 And dotnet core attach is going to attach the debugger to an already running process. 03:21.540 --> 03:23.910 So I already have a running process. 03:23.910 --> 03:27.930 Now this part can catch a few people out because it might be slightly different. 03:27.930 --> 03:32.250 And it does change sometimes as well between Windows and Mac. 03:32.250 --> 03:36.210 So if we're going to attach to a process, we click the play button. 03:36.210 --> 03:40.290 And then we have to find the process where our application is running. 03:40.290 --> 03:45.900 And like I say, it can be somewhat tricky to find the process. 03:45.900 --> 03:47.970 Now on a mac, it's pretty straightforward. 03:47.970 --> 03:50.910 All I do is I look for the API. 03:50.940 --> 03:52.920 Now, there's no details in here. 03:52.920 --> 03:59.220 All I've got is just this API and this is the process I know that my application is running on because 03:59.220 --> 04:00.660 I called it API. 04:00.840 --> 04:06.210 Now if you're on windows and you're not seeing API, then your process. 04:06.210 --> 04:10.260 Because processes on windows are different to processes on a mac. 04:10.290 --> 04:14.400 Processes on windows are EXE or executable files. 04:14.400 --> 04:18.330 So you may need to search for dotnet watch. 04:18.510 --> 04:26.400 And I think you should see more detail about the DLL inside dotnet watch that you're looking for. 04:26.430 --> 04:32.850 You'd be looking for something like api dll, because if we take a look at the file system and we go 04:32.850 --> 04:34.500 to not the. 04:34.680 --> 04:41.880 Net system this time, but we go to restore the file and folder view in API we have a bin folder. 04:41.940 --> 04:44.400 Inside here we have a debug folder. 04:44.400 --> 04:46.950 And this is the process that's running our API. 04:46.980 --> 04:48.390 This API dll. 04:48.390 --> 04:53.460 So effectively you're looking for something that matches this inside this search window. 04:53.490 --> 04:59.760 I know sometimes people have had problems in the past locating the very specific process to debug. 04:59.820 --> 05:02.310 So it might be a case you have to search around. 05:02.310 --> 05:03.000 It should be either. 05:03.180 --> 05:11.550 Net something, it could be API x and it might just be a bit of trial and error if it's not obvious. 05:11.820 --> 05:17.430 And if this one really doesn't work for you, you can always stop your API server from running and then 05:17.430 --> 05:23.670 pick the other option to start the debugger and launch it with your API, and that one will definitely 05:23.670 --> 05:24.330 work. 05:24.330 --> 05:29.130 So anyway, I'm going to go back and search for API and select this. 05:29.130 --> 05:36.450 And what this should do is start our debugger, and it looks like I might have to give a bit of security 05:36.480 --> 05:41.220 or pass through security to give the debugger access to the code. 05:41.220 --> 05:44.910 And sure enough, now the debugger is up and running. 05:45.240 --> 05:48.690 So what we have on the left hand side is we have our debugging tools. 05:48.690 --> 05:50.160 We can see any variables. 05:50.160 --> 05:52.530 We can see things that we want to watch. 05:52.530 --> 05:53.640 And then we've got a call stack. 05:53.640 --> 05:56.670 So we're just going to take a look at this variables section. 05:56.670 --> 05:57.870 But the debugger is running. 05:57.870 --> 05:59.040 We've got our tools at the top. 05:59.040 --> 06:00.420 We can pause the debugger. 06:00.570 --> 06:04.710 Once we've hit our break point, we can then step over the code that we're looking at. 06:04.740 --> 06:12.060 We can step into the code and step out of the code, and we'll also have a play button to go to the 06:12.060 --> 06:16.440 next breakpoint or just continue the request once we've hit this breakpoint. 06:16.440 --> 06:21.090 So I'm just going to go to postman and I'm going to go back to section two. 06:21.120 --> 06:23.280 And I'm going to get an individual product. 06:23.310 --> 06:26.730 Just choose this one API product two I'll click send. 06:26.730 --> 06:29.610 And what should happen is I get taken to the debugger. 06:30.000 --> 06:34.440 Now if we take a look at the variables window, there's quite a lot of information. 06:34.440 --> 06:40.020 Because we're in the context of an API controller, we can see quite a bit of information about the 06:40.020 --> 06:40.620 request. 06:40.620 --> 06:43.980 Also because we're injecting our store context in here. 06:43.980 --> 06:47.190 Then there's also access to this as well. 06:47.430 --> 06:54.330 So that gets a bit detailed because of the amount of information available from the Dbcontext. 06:54.330 --> 06:55.200 So we won't look at that. 06:55.200 --> 07:00.780 But I will take a brief look at the API controller context, because inside here we can see the request 07:00.780 --> 07:07.690 that we've received from postman in this case and we can see the content type, the content, any cookies 07:07.690 --> 07:15.220 we have, any headers that were sent up with this request, and the host values where we're going to. 07:15.250 --> 07:18.820 And inside this request, is there anything else of use? 07:18.850 --> 07:20.290 Well, we can see the path. 07:20.290 --> 07:26.890 And what we'd also have inside an API controller endpoint is when it comes to identity, we can also 07:26.890 --> 07:31.630 get access to the user information, the user that's authenticated to this API endpoint. 07:31.630 --> 07:34.330 And that information is contained inside there. 07:34.360 --> 07:36.160 And we see this. 07:36.190 --> 07:41.590 This keyword is something that we see often. 07:41.890 --> 07:47.650 And because I'm inside a controller and I've hit an API controller endpoint, then this refers to the 07:47.650 --> 07:51.820 products controller itself and what the products controller has access to. 07:51.850 --> 07:57.220 So it's got the controller context, the HTTP context, the model state we took a look at earlier on 07:57.220 --> 07:58.660 in the buggy controller. 07:58.690 --> 08:04.750 And this is where it tracks any potential errors or validation errors inside here it would be added 08:04.780 --> 08:06.220 to this model state. 08:06.220 --> 08:09.340 And then we've got things like our route data. 08:09.370 --> 08:15.190 Where is the request going to in this case the Getproduct method inside the products controller. 08:15.190 --> 08:17.260 And lots of useful information. 08:17.260 --> 08:17.950 So great. 08:17.950 --> 08:19.900 That's useful. 08:19.900 --> 08:23.980 And if we step over we don't have anything about the product inside here yet. 08:23.980 --> 08:29.020 Because whilst we're on this line, we haven't actually gone to our database to go and get the product. 08:29.500 --> 08:34.390 So if I click on Step Over, then I'm going to step over that line of code. 08:34.390 --> 08:39.910 And at this point we now have the product and we can see on the left hand side we've got the details 08:39.910 --> 08:43.240 about the products we retrieved from our database. 08:43.660 --> 08:44.500 So great. 08:44.500 --> 08:46.900 And then we can go ahead and return the product. 08:46.900 --> 08:54.130 And if I step over again and step over again and step over again, then we get taken down the rabbit 08:54.130 --> 09:01.270 hole of what looks to be like the entity class, etc. so I'm just going to play out the rest of the 09:01.270 --> 09:01.750 request. 09:01.750 --> 09:04.780 And if we go back to postman, we can see we've got that returned. 09:04.900 --> 09:11.260 Now, just as a quick example of the other approach where we used the launch the debugger, I'll just 09:11.260 --> 09:15.400 stop the application and I just want to double check this one does work. 09:15.400 --> 09:22.600 It's not something I use typically, because I typically just attach the debugger rather than use this 09:22.600 --> 09:22.930 version. 09:22.930 --> 09:29.590 But we know the DB initializer class is something that we wouldn't be able to add a breakpoint to, 09:30.160 --> 09:33.070 and then find out what's going on by attaching the debugger. 09:33.070 --> 09:37.900 So I'm just going to add a breakpoint here on line 23, just to check to see if we have any products 09:37.900 --> 09:39.460 inside our context. 09:39.460 --> 09:43.660 And I'll just make sure the application is stopped and it is stopped. 09:43.660 --> 09:48.340 And I'll go back to the debugger and I'll choose the other approach this time. 09:48.340 --> 09:52.420 And this time we're going to launch our application with the debugger. 09:52.420 --> 09:53.470 So I'm going to press play. 09:53.470 --> 10:01.600 And what I'd expect to see is I'd expect to stop on this breakpoint whilst our application is starting 10:01.600 --> 10:01.780 up. 10:01.780 --> 10:09.880 So I'll press play and we've got a build failure because let's see users blah blah blah restore forward 10:09.880 --> 10:12.280 slash API csproj failed to build. 10:12.310 --> 10:15.940 Would you like to continue and run the last successful build? 10:15.970 --> 10:21.130 I'm going to say yes, and that didn't work either. 10:21.160 --> 10:24.550 Okay, so what is the problem there? 10:24.580 --> 10:30.820 And it looks like the path is a problem here because this just says restore API Csproj. 10:30.880 --> 10:36.370 The folder that the API Csproj is contained in is actually called API. 10:36.400 --> 10:39.250 So really that should be api API Csproj. 10:39.280 --> 10:41.950 So let's just make that correction. 10:41.950 --> 10:48.340 So I'll go back to the Launch.json and where we've got the project path that's going to need to say 10:48.370 --> 10:52.450 forward slash API and then API Csproj. 10:52.450 --> 10:53.770 So let's give that another go. 10:53.800 --> 10:55.480 I'll hit the play button again. 10:55.840 --> 10:58.120 And this time we should get success. 10:58.120 --> 11:06.020 And I can see that I've hit the breakpoint inside the DB initializer, we can debug and troubleshoot 11:06.050 --> 11:08.090 what is inside here. 11:08.090 --> 11:12.980 So our first check for instance is to check the context dot products to see if there's any products 11:12.980 --> 11:14.300 inside our database. 11:14.300 --> 11:19.460 And just as a quick demo of taking a look at the DB context, because there is something that can catch 11:19.460 --> 11:27.140 people out, if I go to context and I go to products and I go to results view, then we can see our 11:27.140 --> 11:29.360 different products inside here. 11:29.360 --> 11:33.890 So what this is going to tell us that we do have some products in our database. 11:33.890 --> 11:37.160 So we're going to hit the return statement there. 11:37.160 --> 11:40.400 And we're not going to create another new list of products. 11:40.730 --> 11:44.420 So if I was to step over this then I go to the return statement. 11:44.420 --> 11:48.350 And that would then take us out of this block of code. 11:48.350 --> 11:49.760 So I'll just hit the play button. 11:49.760 --> 11:52.370 And then our application would start up as normal. 11:52.370 --> 11:57.290 But we're running in debugging mode as well so we can keep our debugger attached. 11:57.290 --> 12:02.600 But the downside to this is when we make code changes then it normally interferes with a debugger. 12:02.600 --> 12:07.100 and it's more of a case of stopping the application, restarting it again. 12:07.100 --> 12:12.560 So that's one of the reasons I do prefer to use the attach approach when it comes to the debugger. 12:12.560 --> 12:14.960 So that's just a brief overview of the debugger. 12:14.960 --> 12:16.850 It is a very useful troubleshooting tool. 12:16.850 --> 12:22.580 I do recommend practicing using this whenever you run into a problem, just to get used to using it, 12:22.580 --> 12:27.080 just so you can inspect to see what's going on with your dotnet code. 12:27.080 --> 12:34.250 So practice, practice, practice using this and you'll just get used to the tool and get used to seeing 12:34.250 --> 12:36.320 what's going on inside your code. 12:36.890 --> 12:41.750 So anyway I'm going to stop this and I'll just use the normal approach to start the application. 12:41.840 --> 12:46.310 Anyway, this brings us to the end of the section, another milestone reached. 12:46.310 --> 12:49.400 So we're going to save our changes into source control. 12:49.400 --> 12:57.200 I'm just going to stage these changes and give this a message of end of section six and commit this 12:57.200 --> 13:00.770 and sync these changes up with GitHub. 13:00.770 --> 13:03.320 And we'll wrap up with a summary.