VS code docker debug asp.net core

foreword

The birth of .net core is to solve cross-platform things, so it is nothing new for .net core apps to run on linux, macOS, and docker.

I believe that many .net core projects have been deployed in the docker or linux environment. However, the development environment of ordinary developers will not be Ubuntu, redhat or something. Since the difference between the development environment and the deployment environment is relatively large, we always hope that when developing and debugging, it can be closer to the actual deployment environment. So today's article talks about how to debug the asp.net core app deployed in docker.

If you have installed VS2017, this is actually the best, debugging and deployment are all clicking a few buttons, and then you can debug happily.

But there are always cases where VS2017 cannot be installed, so the following is about debugging with VS code.

 

The necessary environment for the development machine:

1. .net core 1.1

2. vs code (try the latest version)

3. docker 17.06.0'

 

Project structure

We use dotnet cli to build the project first, enter the directory to be used, and run the following commands,

dotnet new mvc - n web
dotnet new sln mytest
dotnet sln mytest.sln add web /web.csproj

 

Well, after the project is built, we open it with vs, wait a moment, vscode will automatically create a .vscode folder for us, and there will be some debugging configuration files in it, as shown below:

Open the program.cs file and modify the code of the Main method, mainly to modify the port, in order to avoid conflicts with other ports

copy code
public  static  void Main( string [] args)
{
     var host = new WebHostBuilder()
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseUrls( " http://*:6106 " )
                .UseIISIntegration()
                .UseStartup <Startup> ()
                .Build();

    host.Run();
}
copy code

 

The project is basically complete, but it also needs to be equipped with a Dockerfile, which is mainly pushed to the docker configuration file

We create a new Dockerfile in the web directory with the following content: (Note: this file has no suffix)

copy code
1 FROM microsoft/ dotnet:latest
 2  
3 RUN apt - get update
 4  
5 RUN apt-get install curl unzip -y 6
 7  
RUN curl -sSL https://aka.ms/getvsdbgsh | bash / dev/stdin -v latest - l ~/vsdbg 
8  
9 RUN chmod  777 /root/ vsdbg
 10  
11 COPY ./publish / app
 12  
13 WORKDIR / app
 14  
15 ENTRYPOINT [ " dotnet " , " web.dll" ]
copy code

Briefly explain the above configuration,

Line 1 means the latest version image based on microsoft/dotnet.

Lines 3 and 5 are to update apt-get and install curl and unzip (the last -y is required, otherwise docker will wait there for command input, which will eventually lead to debugging failure)

Lines 7 and 9 are curl to install vsdebuger, and adjust the permissions of this installation directory

Line 11 is to copy the contents of the publish directory in the development environment to the /app directory in the docker image

Line 13 specifies that the docker working directory is /app

Line 15 is the entry point for running, and the translation is dotnet web.dll (a bit like running after local deployment)

 

deploy to docker

We first need to release the .net core app. Note that the Debug mode must be selected, and the release path specified later should also be specified, otherwise the 11th line of the dockerfile will be modified.

dotnet publish -c Debug -o ./publish

After running, there will be more publish directories in the web directory, and there are many dotnet release files below (we won’t talk about the minimum release today, it doesn’t matter if there are more things)

Download the image microsoft/dotnet:lastest from docker, and make your own image myimage1

docker pull microsoft/ dotnet
docker image tag microsoft /dotnet:latest myimage1:latest

After that, we will publish the .net core stuff to docker. The last dot "." is required! ! !

docker build -t myimage1 --rm .

The deployment process depends on your network, because several things need to be installed, among which vsdebuger is quite slow, but it can be solved, we will discuss the solution after the end of the article

When the docker build is complete, we let the app run in the container

docker run -t -p 6106 : 6106 --name mytestcontainer myimage1

Among them, -p 6106:6106 refers to pointing the 6106 port of the local machine to the 6106 port in the container. In fact, there is no one-to-one correspondence here.

--name mytestcontainer means to mirror this myimage1 and run the container with the name mytestcontainer. The advantage is that we only need to remember the name for the operation of our team's container, and we don't need to remember the id that docker automatically generates for us.

Well, the .net core app is running in the container, we open localhost:6106, and we can actually see the effect

 

 vs code debug configuration

 

Open the .vscode/launch.json file. Click Add configuration in the lower right corner to add a debug configuration.

After that, vscode will automatically prompt which debugging configuration to choose. We directly choose .Net: Attach to remote .NET Core Console App (that is, the second one...), as shown in the figure

After clicking, the following configuration will be generated, and there are many things to be changed. There are also some hints, such as debuggerPath is to enter the location of the debugger on the target computer.

 Finally, we need to change the content under the configuration node to the following

copy code
1       {
 2              "name": ".NET Core Attach" ,
 3              "type": "coreclr" ,
 4              "request": "attach" ,
 5              "processId": "${command:pickRemoteProcess}" ,
 6              "pipeTransport" : {
 7                  "pipeCwd": "${workspaceRoot}" ,
 8                  "pipeProgram": "bash" ,
 9                  "pipeArgs" : [
 10                      "-c" ,
11                      "docker exec -i mytestcontainer ${debuggerCommand}"
12                  ],
 13                  "debuggerPath": "/root/vsdbg/vsdbg"
 14              },
 15              "sourceFileMap" : {
 16                  "/Users/admin/my/github/test_debug_docker": "${workspaceRoot}"
 17              }
 18          }        
copy code

where -i mytestcontainer in line 11 is the name of the container we specified earlier, which can also be replaced by id

The debuggerPath in line 13 is the vsdbg downloaded and installed by curl just now. Here, pay attention to where the vsdbg directory is installed when docker builds

The sourceFileMap on line 16 refers to the location of the entire project in your development environment. Simply speaking, it is the directory that vscode you open (this is actually a deeper meaning, and we will not discuss it here)

OK, everything is ready, let's debug it! !

 

debug effect

Press F5, then you will be asked which process to debug, of course select dotnet web.dll

 Wait for some time, then it's ok, then we set a breakpoint in the About method of the homecontroller.cs file

Then open this link: http://localhost:6106/Home/About, you can see that the endpoint in the figure below has entered.

Then you can see his value in the variable on the left, which is the same as the one on the left.

 

We can also modify its value in the debug console, such as entering ViewData["Message"] = "test test"; you can see that the variable on the left has changed

The content of the page has also become test test

 

 

Summarize

In the past, when we debugged the mvc page in vs, we changed the content of cshtml, refreshed the page after saving, and we could see the effect of the change immediately, but not in vs code. It is estimated that it is because of docker, which should be solved later.

Another disadvantage is that attaching to a process is always a disadvantage. He cannot attach multiple processes at the same time. If you want to debug between multiple systems, you can only start multiple vs code at the same time. Compared with the debugging of vs, the difference is too big. . Since the system wants to be deployed in docker, it is estimated that it is modular or even a microservice unit. Such a relatively complete system must be designed for debugging between multiple submodules. Although each module may not be done by the same person, it is better to be able to connect debugging in the development environment.

 

The solution to the super slow download of vsdebugger

In fact, the installation of vsdebugger just downloads the file and puts it in the specified directory.

So the solution is to download this vsdebugger, then unzip it, put it in the web directory of the development environment, and finally configure it with Dockerfile, copy vsdbg to the container, the following is the modified Dockerfile

copy code
FROM microsoft/ dotnet:latest

RUN apt - get update

RUN apt -get install curl unzip -y

# RUN curl -sSL https: // aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ~/vsdbg 

COPY . /vsdbg /root/ vsdbg

RUN chmod  777 /root/ vsdbg

COPY ./publish/app _

WORKDIR / app

ENTRYPOINT [ " dotnet " , " web.dll " ]
copy code

This way you don't have to wait for curl to install vsdebugger.

 

Download link for vsdebugger:

https://vsdebugger.azureedge.net/vsdbg-15-1-10630-1/vsdbg-linux-x64.zip

 

 

 

 

 

 

 

 

 

Related: VS code docker debug asp.net core