Visual Studio的八個調試建議：像老大哥一樣調試
Visual Studio內置有如此之多有用的調試特性，但并非眾所周知。本文列舉一些我的***，包括最近我在 VS2013 中發現的調試特性。
1.在Lambda表達式中的斷點
如果你點擊左邊欄設置斷點，你可能很容易被誤導認為斷點發生在行級別上。實際上，你可以在行內部插入斷點，如在你的LINQ的Lamdba表達式中。僅需右擊代碼部分并且從菜單選擇Breakpoint > Insert breakpoint。
2.便捷的輸出窗口
輸出窗口對調試很有用，同樣斷點也是彈出式或中斷程序的，但它確實很嘈雜。僅需右擊輸出窗口(要確保輸出被設為調試)，關閉Module Load，Module Unload，Process Exit 和Thread Exit 以只輸出你關心的內容。現在用Debug.WriteLine給出你真正關心的內容吧。
你也可以在輸出窗口使用Ctrl-S保存設置。
3.在客戶端和服務器端附加調試(VS2012)
服務器端和客戶端工程在一個solution中是有用的，你僅需要一份Visual Studio運行時拷貝而且也不會在alt-tab鍵的前進后退中迷失，特別是當它們使用共同的代碼如數據結構工程。
有一個缺點，start-up工程是唯一獲得附加調試的工程。如果你遇到異常，它會顯示在你的客戶端，而不是服務端。
現在這個問題很容易解決了。右擊solution，選擇properties > Multiple startup projects，然后選擇Start動作為你需要附加調試的工程。
4.創建可重建工程模板
如果你負責SDK或者API，創建一個你獨用的簡單的應用程序。然后使用File > Export template保存它。
現在你隨時可以從你的模板創建一個新的工程，僅需要一些點擊。更好的做法是使得用戶和測試者能夠使用它們，以便他們給你最小的重建。
5.使用DebuggerDisplay屬性
調試器默認會使用ToString()來監視并在窗口正常輸出類名。即使你重寫ToString，對其他調試者也不見得一目了然。
在你的類中通過一句簡單的表達式，而不是改變屬性值來使用DebuggerDisplay。例如：
- [DebuggerDisplay("Order {ID,nq}")
- class Order {
- public string ID { get { return id; } }
- }
“nq”阻止了雙引號發散。你也可以在這里使用方法，但是別做任何可能帶來微小副作用的事，否則你觀察的對象可能改變其行為，并導致奇怪的事發生。
6.管理斷點
你創建了一些帶勁的斷點，現在你要關閉其中的一個，因為它被點擊了太多次，但你馬上又要再次用到它。如果你刪除了這個斷點，你就不得不回來再找到斷點位置。
打開常被忽視的Breakpoints窗口(Ctrl-Alt-B)。這個窗口顯示了你設置的所有的斷點但關鍵的是允許你使它們無效僅僅通過去除check標記。再次check上以重新使它有效。
這個窗口同樣提供了快速調試的功能：
- 條件 斷點什么時候發生
- 發生次數 觀察多長時間發生一次并基于該次數中斷
- 標簽 斷點在分支中允許有效和無效
- 何時發生 在輸出窗口顯示一條消息以代替真實的中斷
7.斷開或輸出調用者信息(.NET 4.5/Windows 8 Store)
沒有為調用程序當前方法準備的全局變量，并且得到當前棧內容是一個非常慢的操作。
一個快速簡單的手段是，為方法增加一個額外的可選字符型參數了，用CallerMemberName屬性。例如，
- void MyFunction(string someValue, [CallerMemberName] string caller = null) {
- ...
- }
因為這是可選的值，你不必修改任何調用程序，但現在你能：
①基于調用程序變量，在某些程序中設置斷點條件
②向日志文件或者輸出窗口輸出調用程序內容
你也可以使用CallerLineNumber 和CallerFilePath。同樣記住構造函數，終結器和運算符重載將會顯示它們的相關方法名(.ctor,op_Equals等等)。
8.監視方法返回值(VS2013, .NET 4.5/Windows 8.1 Store)
有時你想看看方法返回值但對你來說并不容易，因為它是另一個方法的輸入參數,所以你并沒有存儲該值。
這個功能被加到VS2013中，但是它卻非常容易錯過，你不得不在正確的時間和正確的地方使用它。正確的地方是 Autos窗口，正確的時間是剛好回到方法被調用的地方這一步。當在你調用方法之前或者在方法體中時你看不到這個。它是一個單一步驟，像這樣：
箭頭標明它是返回值，并且讓你知道和它相關的方法名。
寫在***
我也不得不強調，一旦軟件離開了你的機器，記錄日志對問題解決是多么有效。但這是一個比這個更大的議題。
我是不是遺漏了一些更好的調試建議？在下面的回復中隨時讓我知道吧。
附：Michael Parshin也有一些調試的很棒的建議。
原文鏈接：http://damieng.com/blog/2014/02/05/8-visual-studio-debugging-tips-debug-like-a-boss
