DotNet程序的調試，是DotNet程序員必備的技能之一，開發出穩定的程序、解決程序的疑難雜癥都需要很強大的調試能力。DotNet調試有很多方法和技巧。現在本文就介紹一下借助DebugView工具進行調試的方法，以及由DebugView引申出來的知識點。

DebugView

DebugView是一個查看調試信息的非常棒的工具，支持Debug、Release模式編譯的程序，甚至支持內核程序，而且能夠定制各種過濾條件，讓你只看到關心的輸出信息，而且可以定制高亮顯示的內容等等，非常方便。

捕捉Release模式的Win32程序輸出的調試信息，需要選中Capture Global Win32選項：

過濾與高亮功能

可以通過include、exclude設置過濾條件，包含指定字符串的輸出信息將會被過濾。還可以通過exclude條件過濾掉對應進程ID的調試信息。多個條件使用“；”分隔，而且支持“*”通配符。

遠程調試

DebugView支持遠程捕捉調試信息。首先在遠程機器上通過如下命令啟動DebugView：

DebugView.exe /a /t /g /s

這樣，DebugView就會以服務的方式運行，如下圖：

然后在本地機器上啟動DebugView，并通過Connect連接到遠程機器的DebugView，當遠程機器中有調試信息輸出時，本地就會捕獲到，并展示出來：

輸出信息到DebugView的幾種方式

DebugView的一些功能是不是讓你心動了呢。俗話說心動不如行動，但是在行動之前，首先要知道C#如何將調試信息輸出到DebugView中。

通過編程輸出一些調試信息到DebugView中，一共有三種方式：

• Debug.WriteLine
• Debugger.Log
• Kernal32.dll中的OutputDebugString方法

一、Debug.WriteLine

通過Debug.WriteLine可以將調試信息寫入到DebugView中，如下：

Debug.WriteLine("這是調試信息");

效果如下：

不過此方式只能在Debug模式下有效。具體原因下面會詳細介紹。

二、Debugger.Log

Debug.WriteLine已經很好用了，唯一的缺點就是在Release模式下無效。那么在Release模式下就可以使用Debugger.Log方法，示例如下：

Debugger.Log(0, null, "這是Debugger.Log輸出的調試信息");

三、Kernel32.dll中的OutputDebugString方法

做C++開發的應該知道可以通過OutputDebugString這個API開實現輸出調試信息到DebugView中吧。那么C++能做的，C#也能做?？梢酝ㄟ^PInvoke的方式引入此方法，這個API屬于Kernel32.dll，如下聲明：

[DllImport("kernel32.dll", CharSet=CharSet.Auto)]
public static extern void OutputDebugString(string message);

然后就可以通過調用此方法，將調試信息輸出到DebugView中。

DebugView與日志框架比較

可能有人會說，DebugView能做的事情，我用log4Net，NLog等日志框架也能做，為什么要用DebugView呢？

問的好，那么我就根據平時使用DebugView的經驗來給你一個用DebugView的理由：

• DebugView使用非常方便。相比于日志框架龐大的體系，DebugView的使用可謂是十分的簡單方便。DebugView只有幾百K的大小，占用空間幾乎可以忽略不計。從官網下載后，直接運行exe，幾乎不需要任何配置就可以正常使用。而相比于DebugView，日志框架可以算的上龐然大物。而當你從官網獲得log4Net后，需要進行各種繁雜的配置。甚至你要花上幾天時間專門學習一下這套框架。由此可以看出DebugView的使用實在是方便的不能再方便。
• DebugView是可視化工具，支持各種過濾和高亮。DebugView可以通過過濾條件來過濾不關心的信息，只顯示相關的調試信息。而日志框架輸出的是文件等文本信息，這些信息會包含程序運行過程中的所有信息，雖然可以通過配置文件來指定只輸出哪一類信息，但是不如DebugView來的方便簡單。
• DebugView可以實時監視。DebugView中有“自動滾動”的功能，程序中輸出的調試信息，基本上瞬間就會在DebugView中展示出來，當由于大量信息導致DebugView中的文本框滿了后，DebugView可以通過自動滾動滾動條，讓你隨時都可以看到最新的一條信息，達到類似監視的效果。而日志框架由于其寫文本的特性，很難達到這種效果，即使能達到，相信也是需要對日志框架相當清楚了解，才能完成這個效果。

這些理由應該足以讓你使用DebugView了吧。使用DebugView的理由肯定還不止這些，如果你有更好的理由，還請分享出來。

當然，DebugView與日志框架，每個都有每個的用途。通過DebugView的方式，只適合短暫的調試，而正式發布的網站或者軟件，需要一套記錄程序長期以來的運行狀態的工具，那么就非日志框架莫屬了。所以DebugView與日志框架，要在合適的地方，發揮他們最大的功效。

聲明

Log4Net等日志框架，功能足夠強大，也足夠豐富，相信上面說到的DebugView的功能，也可以通過日志框架來實現。但是和DebugView比較起來，會相對復雜一些。所以上面說到的使用DebugView的理由是基于方便性的比較，DebugView有足夠的方便性來讓你選擇使用他。

ConditionalAttribute詳解與條件編譯

說到調試，那么肯定有開發人員遇到這種情況，開發產品的時候，遇到一些問題，就在代碼中加入了大量的調試輸出信息，比如通過Console.WriteLine、MessageBox.Show或者通過Ilog.Log記錄日志，甚至臨時改變邏輯來驗證邏輯的正確性等。經過這些調試信息的幫助，終于解決了產品的問題。但此時又遇到了新的問題，產品最終發布的時候，肯定是不能有這些調試信息的，可是已經加了這么多調試信息，難道要全部刪除掉嗎。這顯然不是一個好辦法，這么多代碼，手一抖，很容易就刪除了不相關的代碼，造成不可預估的后果。

做過C/C++開發的，可以從各種跨平臺的開源庫中看到，一堆一堆的#if....#else....#endif，這就是條件編譯，這也是C/C++跨平臺所依賴的最基本的東西，在Linux系統，編譯這段代碼，在Windows系統又編譯那段代碼，最終實現了代碼級別的跨平臺。

那么C#中有沒有類似的功能呢，答案當然是有，而且有兩種：

• 通過給方法加上ConditionalAttribute特性
• 使用#if..#else..#endif，來控制代碼的編譯

ConditionalAttribute特性

下面是ConditionalAttribute的構造函數：

public ConditionalAttribute(
    string conditionString
)

構造函數中的參數conditionString，是一個區分大小寫的條件編譯符號的字符串。

上面提到Debug.WriteLine時，說到這個功能只在Debug模式下才有用，Release下就不起作用了。

我們從MSDN中看一下Debug.WriteLine的說明：

[ConditionalAttribute("DEBUG")]
public static void WriteLine(
    string message
)

由此也就明白了Debug.WriteLine只能在Debug模式下使用，而在Release模式下無效的原因了。

條件編譯#if..#else..#endif

C/C++中有#if..#else..#endif，C#中也有這些，他們都被稱為預處理器。通過預定義的條件編譯符號，來控制編譯時編譯哪部分代碼。如下：

public bool HasPermission(string userName)

{

#if DEBUG

    //Debug模式下，不需要做權限判斷，直接返回true

    return true;

#else

    //Release模式下，只有sa用戶才有權限

    if (!string.IsNullOrEmpty(userName) && userName == "sa")

    {

        return true;

    }

    else

    {

        return false;

    }

#endif

}

預定義的Debug宏在什么地方

說到條件編譯，是不是只有DEBUG 和 RELEASE兩種情況呢，如果是這種情況的話，那也就是說DEBUG和RELEASE兩種情況是定義好了的，俗話說就是“做死了”，這是作死的節奏啊。不作死就不會死，至少VS在這點上還沒有作死。

讓我們來一步步揭開DEBUG的面紗。

既然是條件編譯，那么就應該和編譯選項有關。我們知道C#項目，有一個屬性頁，可以設置很多編譯的選項，如下：

從圖中看到，條件編譯是用的DEBUG常量，或者稱為DEBUG條件編譯符號，是在這個編譯生成選項中定義的，如果去掉這個定義，那么編譯后的HasPermission方法就會根據用戶名進行權限檢查，程序中通過Debug.WriteLine輸出的調試信息也會輸出到DebugView中，也就相當于Release模式下的效果。

其實DEBUG常量與Debug、Release模式并無太大的關系，唯一的關系就是，VS生成的項目中，Debug模式下，默認會選中“定義DEBUG常量”，而Release模式下，默認不會選中。也就是說，Debug模式，默認會定義DEBUG常量，而Release不會，如下圖：

既然DEBUG常量與Debug模式無本質上的關聯，那么為什么說到Debug，就認為DEBUG呢。道理其實很簡單，世上本無路，走的人多了，便成了路。本來這個DEBUG常量只是Debug模式下的默認預定義的常量，只是因為大家習慣了，并且對它的這種預定義還比較認可，時間久了，就自然而然認為DEBUG就代表Debug模式。

雖然我們可以通過去掉DEBUG常量，來使條件編譯在Debug模式下達到Release模式的效果，但是建議最好不要這樣做，因為這就像是大家普遍都認可的一個約定，如果你一反常態，不遵守這個約定，對于程序，編譯沒有問題，但是后續維護肯定會相當麻煩，所以還請大俠手下留情。

使用自定義的編譯常量

DEBUG常量作為一種普遍的約定，最好不要打破。如果有除DEBUG外的條件編譯需要，可以使用自定義的編譯常量。

自定義編譯常量有兩種方法：

• 通過編譯生成屬性頁中的條件編譯輸入框，定義自己的編譯常量。
• 在代碼中使用#define預處理，來定義編譯常量。

我們可以在條件編譯的輸入框中，定義自己的編譯常量，多個常量之間用分號“;”隔開，而且支持中文常量，如下：

當然，我們也可以在代碼中通過#define預處理來定義，比如：

#define 緣生夢
#define hbccdf

但是有一點需要注意，define定義常量必須在using 命名空間之前，否則會造成編譯錯誤。

通過VS和Resharper改變顏色來查看哪些代碼真正會被編譯

引入條件編譯后，我們可以通過VS很快知道哪些代碼會被編譯：

雖然條件編譯的代碼可以很直觀的看出來，但是Conditional修飾的方法就看不出來了，這時就要借助神器Resharper了，如下圖：

從圖中看出，release模式，由于沒有定義DEBUG、緣生夢兩個常量，所以，調用Test、Debug.WriteLine方法的地方就會變暗，這樣很直觀就知道這些代碼不會被編譯。再次說明一個道理，神器對于開發有很大的幫助作用。

通過反編譯查看生成后的代碼

上面總是說，有些代碼會被編譯，有的則不會，那么真正編譯后的效果是怎樣的，我們不妨使用另外一個比較強大的工具，反編譯工具Reflector，來查看一下反編譯后的代碼：

從圖中的反編譯后的代碼可以看出，滿足條件的代碼會真正編譯到生成的程序集里，而不滿足的代碼則不會生成到程序集里。

Conditional修飾的方法，會有方法的實現，但是沒有方法的調用。不適合在方法里做一些變量的修改。

總結Conditional和條件編譯

• Conditional為方法級別的條件編譯，只能修飾方法；#if..#else..#endif為行級別的條件編譯，可以指定任意代碼。
• Conditional只能修飾無返回值的方法，而且不適合在方法中處理一些變量的值。#if..#else..#endif沒有任何限制。
• 可以通過條件編譯符號輸入框，或者代碼中的#define定義條件編譯常量，這些常量對于Conditional、#if..#else..#endif均有效。

TRACE常量

從上面多幅圖中，可以看到，在Debug和Release模式下都會定義一個TRACE常量。

現在我們知道DEBUG常量是用來控制調用Debug.WriteLine的語句是否被編譯。那么TRACE常量呢。

相信很多人也用過System.Diagnostics.Trace類，由DEBUG常量與Debug有關，可以想到TRACE常量與Trace有關，我們來看一下MSDN對于Trace的定義。

從MSDN中，看到Trace類的定義以及可以調用的方法與Debug類似，都有WriteLine方法。下面是Trace的WriteLine方法定義：

[ConditionalAttribute("TRACE")]
public static void WriteLine(
    string message
)

由此可以知道，TRACE常量是用來控制Trace類中WriteLine等方法是否被編譯的作用。

Debug類與Trace類的區別

到現在為止，我們漸漸的了解了Debug類與Trace類，他們都可以通過WriteLine方法輸出調試或跟蹤信息，從他們的定義和暴露的方法中，可以看出他們非常相似，那么他們有什么區別呢。

有些人會根據使用的效果總結為：Debug類只能在Debug模式下執行，在Release模式下無效果，而Trace類在Debug和Release模式下都可以執行。

確實，在VS中新建一個項目，分別調用Debug.WriteLine和Trace.WriteLine方法，只有Trace.WriteLine輸出的信息，在Release模式下有效。這也看似驗證了上面的區別。

但這是他們兩個真正的區別嗎。我們一點一點來分析。

首先看這兩個方法的定義：

由圖看到，每個方法都通過ConditionalAttribute關聯了一個條件編譯常量，Debug關聯DEBUG常量，Trace關聯TRACE常量。再來看一下這兩個常量的定義：

從圖中看到，TRACE在Debug和Release模式下都會定義，這樣在Debug和Release模式下都會執行，而DEBUG只在Debug模式下才會定義，Debug.WriteLine只在Debug模式下執行。從而也驗證了上面的結論。

但DEBUG與TRACE只是在默認的情況下的定義。當改變這些定義后，上面的結論就不再正確。

我們來做這樣的實驗：Debug模式下只定義TRACE常量，Release模式只定義DEBUG常量

然后在Debug和Release模式下分別執行Debug.WriteLine方法和Trace.WriteLine方法，Debug.WriteLine方法只在Release模式下有效，而Trace.WriteLine方法只在Debug模式下有效。上面的結論不再成立。

為了更好的驗證一下我們的結論，對他們進行反編譯：

由圖中的反編譯代碼看到，除了關聯的條件編譯常量不同外，內部調用的方法均為TraceInternal.WriteLine，實現完全一樣。

那么下面來總結一下Debug與Trace的區別：

• Debug類關聯DEBUG常量，Trace類關聯TRACE常量。
• 默認情況下，VS創建的項目Debug模式會定義DEBUG與TRACE，而Release模式只定義TRACE，使Debug只在Debug模式有效，而Trace在Debug和Release模式均有效。
• 可以通過修改DEBUG、TRACE的默認定義，來改變Debug、Trace的默認行為。但是建議最好不要這樣做，因為改變了這種默認的約定可能會出現意想不到的問題。

Debug、Debugger、Kernel32的聯系

每個人大腦的空間都是有限的，零散的知識很容易忘掉，輸出調試信息到DebugView中的三種方法，由于關聯性不是很強，很容易會忘掉其中的一兩種，那么既然實現相同的功能，他們之間有什么關聯嗎。

這就要從Debug的MSDN文檔說起。

我們知道Debug編譯的程序，運行的時候可以通過Debug.WriteLine方法輸出調試i信息到DebugView，而MSDN中的解釋

將后跟行結束符的消息寫入 Listeners 集合中的跟蹤偵聽器。

并沒有說是輸出到DebugView中，而是寫入到Listeners集合中的跟蹤偵聽器。為了弄明白原理，有必要深入的研究一下。這時就要依賴反編譯工具Reflector了。

從整體看上去，Debug類的每一個方法都通過Conditional與DEBUG常量管理，也就是默認情況下，Debug類的所有方法在Debug模式下均不會編譯。

我們再來具體看一下Debug.WriteLine方法：

[Conditional("DEBUG"), __DynamicallyInvokable]
public static void WriteLine(string message)
{
    TraceInternal.WriteLine(message);
}

再來看一下TraceInternal方法：

public static void WriteLine(string message)

{

    foreach (TraceListener listener in Listeners)

    {

        listener.WriteLine(message);

        if (AutoFlush)

        {

            listener.Flush();

        }

    }

    return;

}

上面的代碼是精簡后的代碼。從代碼中看到會調用集合中的每一個listener的WriteLine方法。

那么這些listener的WriteLine又做了什么呢：

public abstract class TraceListener : MarshalByRefObject, IDisposable
{
    public abstract void WriteLine(string message);
}

原來TraceListener的WriteLine是抽象類的抽象方法，那么我們得到的listener是具體類的一個抽象，相當于接口，這是微軟的一貫做法，再繼續下去，就需要知道是哪些具體的TraceListener了。

繼續上面的線索，我們是從Listeners屬性中獲取到的TraceListener，那么就去看Listeners的get實現：

public static TraceListenerCollection Listeners

{

    get

    {

        InitializeSettings();

        if (listeners == null)

        {

            lock (critSec)

            {

                if (listeners == null)

                {

                    SystemDiagnosticsSection systemDiagnosticsSection = DiagnosticsConfiguration.SystemDiagnosticsSection;

                    if (systemDiagnosticsSection != null)

                    {

                        //從配置文件獲取listener，但是由于此處沒有設置配置文件，所以先不研究這個地方

                            listeners = systemDiagnosticsSection.Trace.Listeners.GetRuntimeObject();

                    }

                    else

                    {

                        //這里new了一個TraceListener的集合

                            listeners = new TraceListenerCollection();

                        //這里我們看到了TraceListener的具體實現類DefaultTraceListener

                        TraceListener listener = new DefaultTraceListener {

                            IndentLevel = indentLevel,

                            IndentSize = indentSize

                        };

                        listeners.Add(listener);

                    }

                }

            }

        }

        return listeners;

    }

}

從代碼中，找到了具體的實現類DefaultTraceListener，那么就快點看看他的WriteLine方法吧，有點迫不及待了。

實際上，WriteLine方法會調用內部的Write方法：

private void Write(string message, bool useLogFile)

{

    if (base.NeedIndent)

    {

         //寫縮進，實際是空格

          this.WriteIndent();

    }

    if ((message == null) || (message.Length <= 16384))

    {

         //輸出消息

          this.internalWrite(message);

    }

    else

    {

        //當消息很長時，會通過internalWrite方法將消息多次輸出

         int startIndex = 0;

        while (startIndex < (message.Length - 16384))

        {

            this.internalWrite(message.Substring(startIndex, 16384));

            startIndex += 16384;

        }

        this.internalWrite(message.Substring(startIndex));

    }

    if (useLogFile && (this.LogFileName.Length != 0))

    {

       //輸出到日志文件中

        this.WriteToLogFile(message, false);

    }

}

與輸出信息有關的有兩個地方，一個是調用internalWrite，另外一個是WriteToLogFile。從WriteToLogFile是有執行條件的。感興趣的可以研究一下。重點來看一下internalWrite方法。

private void internalWrite(string message)

{

    if (Debugger.IsLogging())

    {

       //調用Debugger.Log方法，這個方法可以輸出信息到DebugView中

        Debugger.Log(0, null, message);

    }

    else if (message == null)

    {

        SafeNativeMethods.OutputDebugString(string.Empty);

    }

    else

    {

       //調用Native方法

        SafeNativeMethods.OutputDebugString(message);

    }

}

internalWrite中調用了兩個比較重要的方法。其中Debugger.Log方法是不是很熟悉呢。我們剛剛在上面總結了三種輸出調試信息到DebugView的方法，其中就包含了Debugger.Log，而Debug.WriteLine方法中，又會調用到Debugger.Log方法，這樣，這兩個方法就建立起了聯系。

再來看SafeNativeMethods.OutputDebugString，看到這個類的命名，以及對Win32API的了解，就能想到，這肯定是通過PInvoke等方法對Win32API的封裝，看其定義：

[DllImport("kernel32.dll", CharSet=CharSet.Auto)]
public static extern void OutputDebugString(string message);

果然，這就是對kernel32.dll中的OutputDebugString的封裝調用，而這又是上面三種方法其中的一種。好了，這樣Debug、Debugger、OutputDebugString就全都聯系到了一起，他們之間有了聯系，是不是就更容易記憶了。

配置TraceListener

從上面對Debug.WriteLine的一步步跟蹤分析的過程中，我們看到了對于TraceListener的獲取，一種方式是DefaultTraceListener，另外一種就是如下：

SystemDiagnosticsSection systemDiagnosticsSection = DiagnosticsConfiguration.SystemDiagnosticsSection;

if (systemDiagnosticsSection != null)

{

     //從配置文件獲取listener，但是由于此處沒有設置配置文件，所以先不研究這個地方

    listeners = systemDiagnosticsSection.Trace.Listeners.GetRuntimeObject();

}

這幾行代碼就是從配置文件的system.diagnostics中獲取TraceListener。

關于配置文件具體的讀取和解析過程，本文就不再詳細介紹了，感興趣的朋友可以自行研究，或者等到我的后面博文詳細介紹。

那么現在主要說一下如何通過配置文件來設置TraceListener，如下：

<configuration>

   <system.diagnostics>

      <trace autoflush="true" indentsize="2">

         <listeners>

            <add name="myListener" type="System.Diagnostics.ConsoleTraceListener" />

         </listeners>

      </trace>

   </system.diagnostics>

</configuration>

同樣，有配置文件，那么就可以通過代碼來實現同樣的功能，如下：

Debug.Listeners.Add(new ConsoleTraceListener());
Debug.AutoFlush = true;
Debug.WriteLine("這是Debug.WriteLine輸出的調試信息");

Debug編譯與Release編譯的區別

Debug與Release的區別，這個問題，相信很多人都會有疑問，也會有很多人有自己的答案，我聽到過的答案有這些：

• Release比Debug運行速度快，執行效率高。
• Debug 是調試用的，可以打斷點執行。Release是發布用的，不能打斷點執行。
• Debug編譯的文件大，Release生成的程序集小。
• Debug會生成pdb文件，Release不生成pdb文件。

這些答案看上去好像都對，但是為什么Debug與Release有這么大的區別呢，這就需要深入的思考一下。

在Debug類與Trace類的區別一節中，相信有些朋友已經明白，Debug編譯與Release編譯的區別其實是編譯配置的不同，DEBUG、TRACE常量的定義就是其中不同的地方。那么Debug編譯與Release編譯還有什么不同呢。針對這個問題，我總結了一下，主要區別有下面幾點：

• 常量定義不同
• 優化代碼的不同
• 包含的調試信息不同
• 輸出路徑不同

接下來，我們詳細的看一下。

常量定義不同

這個相信大家已經非常清楚了，Debug模式下會定義DEBUG、TRACE常量，而Release模式下只定義TRACE常量，如下圖所示

優化代碼不同

Debug模式下，默認不會進行代碼的優化，而Release模式下，由于默認選中了“優化代碼”選項，所以編譯器會對生成的代碼進行優化，以提高運行速度。

包含的調試信息不同

編譯生成的屬性頁中有一個“高級”按鈕，點擊后會彈出一個對話框，然后可以對編譯生成進行一些設置，如下

Debug與Release的高級選項對比：

從圖中看到，Debug模式下默認會生成全部的調試信息，而Release模式下只生成pdb文件。

輸出路徑不同

這一點詳細大家都很清楚了，Debug模式下會輸出到Debug目錄，Release模式下會輸出到Release目錄，如圖：

Debug編譯與Release編譯的區別總結

說了這么多，我們再來思考本節開始時說到的關于Debug編譯與Release編譯的區別的答案，可以得出這樣的結論：

• Release比Debug運行速度快，執行效率高。由于Release模式編譯會對生成的代碼進行優化，所以會使生成的程序集在運行的時候比Debug編譯的程序集運行速度快。
• Debug 是調試用的，可以打斷點執行。Release是發布用的，不能打斷點執行。由于Release模式對代碼進行優化，生成的調試信息只包含pdb文件，所以導致調試起來會比較困難。
• Debug編譯的文件大，Release生成的程序集小。依然是由于Release模式對生成的代碼進行了優化，所以就導致生成的程序集相對來說比較小。
• Debug會生成pdb文件，Release不生成pdb文件。這個要看VS的默認選項，在2012中，Release模式默認會生成pdb文件的，其他版本的VS可能會有不同的情況。

知道這些區別后，我們就可以通過修改編譯配置來使Debug程序達到Release的效果，使Release程序達到Debug的效果。當然，還是那句話，雖然可以實現這樣的效果，但是建議絕對不要這樣做，不然程序維護起來，肯定會遇到很多問題。

總結的重要性

有人說，互聯網這么發達，遇到什么問題直接谷歌百度，內事不決問百度，外事不決問谷歌。但是即使你通過網絡解決了問題，如果不消化吸收，經過總結變成自己的東西，那么下次還會遇到同樣的問題。書到用時方恨少，一回首，已白了少年頭。如果不總結，任他虐我千百遍，我卻視他如初見，從網絡上找到的方法、代碼、解決方案，那是別人的知識，只有經過實踐去驗證，通過總結，消化吸收，才能將這些知識“據為己有”，為我所用。

那么至少從現在做起，把每天學到的知識，遇到的問題，得到的經驗，總結下來，相信自己，這是大牛的節奏。