Use Visual Studio Code to debug a .NET Core MVC web application that is running inside a Docker container.
- [Instructor] Now we are going to set up our application so that we can debug it inside a running docker container. Why do we want to debug inside the container? The whole idea of containers is to give us a consistent environment for our application. If we're not using containers as part of the development process, there could be unforeseen differences that cause problems. Even if you don't use a container for the whole development process, debugging inside the container can be very handy for troubleshooting issues. For our setup, we will use Visual Studio Code to attach to a debugger inside the container.
The debugger will run the app, which thanks to something called Volumes, will actually use the code that's on our development computer. Once the application is running, we can access the web app using the ports we defined in the configuration. Finally, we can make changes to our code, and see them reflected without restarting the container. Let's step through this again, this time showing the required configuration files. The first step is to use a docker file to create a container that contains the .NET Core debugger. Here we have a docker file called Dockerfile.debug.
This is going to download the debugger and place it in a VS Debug directory. Another thing to note in here is the entry point step. This step will keep the container running indefinitely, so that we don't have to start the container every time we make a code change. The next step is to use docker-compose to define the port we will use to access our application, and the volume that links our source code from our dev machine to the running container. To do this, we're going to use a docker-compose.debug file. This will define a service that will expose our application on Port 8084.
And it will link our publish directory to the app folder in the container. Two other things to note in this file: we've also linked the NuGet package directory so that we can use packages from our development computer. And we've set the ASP.NET Core environment variable. This tells .NET what environment we're working with, and allows things like having separate settings or separate configuration based on environment. The final step is to use a launch.json file to configure the VS Code debugger to connect to the debugger inside the container and launch the web application.
Launch.json is used to tell VS Code how to launch your application. In this case, it uses PowerShell to connect to the running container and tells the debugger which DLL we will be debugging. Now that we've explained the configuration, let's try it out. The first thing we need to do is restore our packages with .NET Restore. Sometimes when you try and restore packages, you get an error like the one above. If you wait a second, a dialog will come up asking you to hit Restore.
If you do that, then everything should work fine. Next, we will publish the code to a directory that will be linked to our running container. I set up a task for this in the tasks.json file. You can see on line 14 that the .NET CLI is used to publish the application in debug mode to the object Docker/publish directory. Also because line 15 is set to isBuildCommand, we can use Control + Shift + B to run this task. Let's do that now.
Okay, let's take a look. So now we should have our files published into this docker directory, and there they are. So that's good. Let's run our debugging container using the docker-compose file. Again, we can use the docker extension to run our docker compose file. We'll do Docker Compose Up. And we're going to pick our docker-compose.debug file that we were looking at earlier.
Now that the container is running, we need to connect the VS Code debugger. Let's open the debugging window and click Start. Now that the debugger's running, let's set a break point and see it work. Sometimes even though the code is compiled and running, you'll get these red reference errors showing in the editor. If you restart Visual Studio, these errors will go away. They shouldn't have any impact on our process right now, so I'm just going to keep moving.
So let's set a break point here at the view, and now that our application's running, let's open up our web browser, and see if we can stop at this break point. There, we can see that the debugging is working, and we're able to stop at this break point, and then see the code that's being run. So now I'm going to continue from here. And the next thing we want to try is to make a change and to see that change reflected without restarting our container. So I'm going to modify a view.
We're going to go to Views, Home, and Index. This is the view that we were just looking at in the web browser. I'm just going to modify this line. I'm going to copy this line, and paste it so that we see the machine name twice. And then I'm going to use the task that I created earlier to republish the code. So hit Control + Shift + B, just republish our changes. And then I will go back to the web browser, and we'll refresh this page. See that our break point was hit, so we're still debugging.
Press continue, and there we see the machine name listed twice. So now that we've successfully debugged our application inside of the container, let's shut down the debugger using docker-compose. And we can see that our container's stopping, and our container's stopped, it looks like I had forgotten to stop the debugger in Visual Studio before I stopped the container. So, we got an error about Visual Studio can no longer talk to the debugger. That's because we just turned it off in the container. So that's okay. Normally you would go into the debugging and stop your debugger before you stop your container.
- Setting up your environment
- Adding Docker support to an application
- Debugging container-based apps in Visual Studio 2017
- The DevOps life cycle with Visual Studio and VS Team Services
- Configuring release and build
- Azure hosting options
- Using Kubernetes with Azure