一路踩坑，被迫聊聊 C# 代碼調試技巧和遠程調試

一：背景

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