Step on the pit all the way, forced to talk about C # code debugging skills and remote debugging

Time:2021-1-16

1: Background

1. Tell a story

Every time a project is pre delivered, there will always be various wonderful pits. I think it’s necessary to sort out and how to solve them quickly, so that later generations can avoid them. This article talks about what I heard and met

  • I’ll go. The local environment code runs smoothly. There’s something wrong with the test environment
  • I’ll go. There’s a bug in the DLL provided by the third party

2: The solution of two big pits

1. There is no problem with the local environment. There is a problem with the test

I believe many of my friends have similar experiences with me. It’s clear that the program code and configuration files are all the same. If you move a nest, there will be a problem. You say it’s irritating. Since the problem has happened, how can it be solved quickly? Yes, it’s just debugging, but it’s unrealistic to deploy the program on CentOS and send a visual studio to it. How do you want to debug under this kind of restriction? Yes, you can debug remotely. Then you quickly find out that a certain environment variable in the test machine is wrong, and the whole story is clear. Next, let’s see how to realize remote debugging from local to CentOS.

1) Test code

For the convenience of demonstration, I read the strategy environment variable in action.


    public class HomeController : Controller
    {
        public IActionResult Index()
        {
            ViewBag.strategy = Environment.GetEnvironmentVariable("strategy");

            return View();
        }
    }

2) Install SSH

To debug remotely, you need to install SSH on the remote machine, because you need to use SSH to debug additional processes.


yum install openssh-server unzip curl

After the installation, you can see that port 22 has been started


[[email protected] data]# netstat -tlnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1126/sshd           
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      3037/cupsd          
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1739/master    
tcp6       0      0 :::22                   :::*                    LISTEN      1126/sshd           
tcp6       0      0 ::1:631                 :::*                    LISTEN      3037/cupsd          
tcp6       0      0 ::1:25                  :::*                    LISTEN      1739/master  

3) Release configuration of program

In terms of release configuration, the first one is to ensure the debug version, and the second one is to ensure the portable mode, as shown in the following figure:

Step on the pit all the way, forced to talk about C # code debugging skills and remote debugging

4) Debugging with additional processes

In the menu bar, select debug > attach to process, and then fill in all kinds of information required by SSH, as shown in the following figure:

Step on the pit all the way, forced to talk about C # code debugging skills and remote debugging

After clicking connect, you can see the dotnet program process number of the remote machine. Select the process to attach and select it in select code typeNanaged (.NET Core for Unix)As shown in the figure below:

Step on the pit all the way, forced to talk about C # code debugging skills and remote debugging

5) Smooth debugging

In the browser, type:http://192.168.142.130/Home/Index, you can see that my C # code is hit, and you can get the environment variables of the remote machine, so the problem can be solved.

Step on the pit all the way, forced to talk about C # code debugging skills and remote debugging

2. There is a bug in the third party DLL

In addition to F9 debugging, I believe many friends know that breakpoints can be edited, such as: set expression breakpoints, filter breakpoints, hit times breakpoints, action breakpoints, as shown in the following figure:

Step on the pit all the way, forced to talk about C # code debugging skills and remote debugging

The first question is, can you really use these fancy breakpoints? Do you really use it often?

If you let me answer, I won’t use it unless I have to. I prefer to add test statements conducive to debugging into the code for three reasons

  • More flexible

It’s obvious that it’s much more troublesome to set conditions in the panel than to set them with pure statements. Point to point, and condition superposition is also necessary. It’s very complicated. I don’t like it.

  • Powerful function

There are only simple and relationships on the edit panel, and each condition is at the same level, so it is impossible to achieve the inclusion relationship of each condition or relationship, level or recursion, so… no way out…

  • Easier to keep

This is interesting. Right click on the breakpoint to pop up the edit panel, and left click to close the breakpoint. The problem is here. Often because of cheap hands, I want to right click, but I left click…. It’s not easy to set up a good condition… It’s really gone. From then on, the road turns black. As shown in the figure below:

Step on the pit all the way, forced to talk about C # code debugging skills and remote debugging

Is that really useless? I think I can only show my skills in debugging scenarios where I can’t modify statements. For example, the DLL encapsulated by the debugging manufacturer I met, ha ha, now that I’m talking about breakpoints, I’ll use dnspy to demonstrate a few breakpoints for you to review!

1) Test code

For the convenience of demonstration, the for loop case is the best.


        public static void Main(string[] args)
        {
            var sum = 0;

            for (int i = 0; i < 10000; i++)
            {
                sum += i;
            }

            Console.WriteLine($"sum={sum}");
        }

2) I want to hit the breakpoint when sum = 1035

You can use the conditional expression breakpoint, which is very simple, as follows:

Step on the pit all the way, forced to talk about C # code debugging skills and remote debugging

3) Find all the numbers divisible by 1800, and record the I and sum values at that time

Here you can use the action breakpoint logging. In the for loop iteration, you don’t need to interrupt the breakpoint, just need to record the current I and sum values in a specific state, which is very helpful for debugging code, as shown in the following figure:

Step on the pit all the way, forced to talk about C # code debugging skills and remote debugging

3: Summary

In general, these two experiences are also my step-by-step experience. If I can help you, it would be better. I’ll talk about so much in this article. Goodbye in the next!

More high quality dry goods: see my GitHub:dotnetfly