乐趣区

关于c#:一路踩坑被迫聊聊-C-代码调试技巧和远程调试

jiezi

一：背景

1. 讲故事

每次我的项目预交付的时候，总会遇到各种奇葩的坑，我感觉有必要梳理一下以及如何疾速解决的，让起初人避避坑，这篇就聊聊本人的所闻所遇：

  • 我去，本地环境代码跑的哧溜，上了测试环境出问题
  • 我去, 第三方提供的 dll 跑出 bug 了

二：两个大坑的解决方案

1. 本地环境没问题，上了测试出问题

置信很多敌人都有我这样相似的遭逢，明明程序代码，配置文件都一样，挪了一个窝就出问题，你说气人不，既然问题出了那怎么疾速解决呢？对，就是用调试，但程序部署在 centos 上，送一个 visualstudio 下来也不事实，在这种限制级条件下还想调试怎么办呢？不错，能够上近程调试，而后就很快查到了测试机器中的某一个环境变量搞错了，事件的前因后果搞清楚了，接下来就看看怎么实现 local 到 centos 的 近程调试。

1) 测试代码

为了不便演示，我就在 Action 中读取 strategy 环境变量。


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

            return View();}
    }

2) 装置 SSH

要近程调试，须要在远端机装置 SSH，因为前面附加过程调试 就要借助 SSH 买通。


yum install openssh-server unzip curl

装置实现后，就能看到 22 端口已启动 


[root@localhost 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) 程序的公布配置

公布配置上，第一个要确保是 debug 版本，第二个要确保是 可移植模式 (Portable), 如下图：

4) 应用附加过程调试

在菜单栏顺次抉择：Debug -> Attach To Process，而后填写 ssh 须要的各种信息，如下图：

点击 Connect 后，就能看到远端机器的 dotnet 程序 过程号，抉择该过程进行附加，在 Select Code Type 中抉择 Nanaged (.NET Core for Unix) 即可，如下图：

5) 顺利调试

在 浏览器中键入：http://192.168.142.130/Home/Index，能够看到我的 C# 代码被命中，也顺利的拿到了远端机器的 环境变量，问题也就迎刃而解。

2. 第三方 dll 出 bug 了

调试程序除了应用 F9 进行调试，置信也有不少敌人晓得断点是能够编辑的，比如说：设置表达式断点，过滤器断点，命中次数断点，动作断点，下如图：

第一个问题就来了，这些花式断点，你真的会用吗？真的会常常用吗？

让我来答复的话，不到万不得已我是不会用的，我更违心在代码中退出利于调试的测试语句，起因有三点：

  • 更加灵便

这个不言而喻，在面板中设置条件相比用纯语句设置要麻烦得多，点来点去，而且还要条件叠加，简单的很，我是不喜爱。

  • 功能强大

编辑面板上只有简略的并且关系，而且各个条件还是同级别的，无奈做到各个条件的或者关系以及层级或者递归的蕴含关系，所以。。。没方法。。。

  • 更易于保留

这个就有意思了，在断点上右键是弹出编辑面板，点击左键是敞开断点，问题就出在这里，常常因为手贱，本想点右键后果点了左键 ????????????。。。。好不容易设置好的条件没了。。。真的没了????????????，从此以后，路转黑。如下图：

那这么说断点编辑真的没用吗？我感觉只有在不能批改语句的调试场景下可能大显神通，比方我遇到的调试厂家封装的 dll，哈哈，既然说到了断点，我就用 dnspy 演示几个断点给大家温习一下吧！

1) 测试代码

为不便演示，用 for 循环案例是最好的。


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

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

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

2) 我心愿在 sum = 1035 的时候命中断点

这个用条件表达式断点就能够了，非常简单，如下所示：

3) 找到所有可能被 1800 整除的数，并且记录下过后的 i 和 sum 值

这里就能够用到 Action 断点的日志记录，在 for 循环迭代中，不须要中断断点，只需记录某一个特定状态下以后的 i 和 sum 的值，对调试代码十分有帮忙，如下图：

三：总结

总的来说这两个教训也算我一步一步踩坑过去的，如果能帮到你就更好了，本篇就聊这么多，下篇再见！

更多高质量干货：参见我的 GitHub: dotnetfly

更多高质量干货：参见我的 GitHub: dotnetfly

退出移动版