跟蹤和調試語句

我對如何使用.NET跟蹤和調試類有點困惑。跟蹤和調試語句

爲什麼你會打擾使用Trace而不是Debug？

Trace.TraceError() 
Trace.TraceInformation() 
Trace.Assert() 

Debug.WriteLine() 
Debug.Assert()

而且，我的理解是，當你在Release配置模式，但如果跟蹤語句應用的時候，它如何影響性能調試語句將被忽略？

來源

2008-12-31 Vince Panuccio

之間的網絡傳輸問題可能的重複：http://stackoverflow.com/questions/179868/trace-vs-debug-in-net-bcl – user 2013-01-08 12:50:12

最簡單地說，他們有不同的編譯開關 - 即Debug.WriteLine等，如果你有DEBUG編譯符號（不常見的發佈版本）僅切換，其中，作爲Trace.WriteLine通常會被列入甚至在發佈版本。

的Trace路由具有可定製的跟蹤監聽器，可通過配置來在鉛垂; Debug通常作爲偵聽器進入調試器。當然，還有第三方跟蹤系統提供更多的靈活性。

來源

2008-12-31 10:44:14

您可以用編譯器開關打開和關閉兩種independantly，如果你去到你的項目屬性的生成頁面，你有一些複選框那裏。

對我來說，經驗法則是我使用調試的實際調試信息，即變量x在這一點上的值是... etc和跟蹤控制通過我的應用程序的流量跟蹤（更多的垃圾郵件）。

來源

2008-12-31 00:24:10

正如您所說，跟蹤調用僅在您處於發佈模式時執行。在發佈模式下編譯具有您可能需要的最終應用程序的一些性能優勢，並且可能還有其他原因希望打開發行模式。但是，有時可能需要將信息記錄到跟蹤控制檯，可以使用SysInternal's DbgView等應用程序查看這些信息。這些通常是不需要發送到日誌輸出的消息，或者即使用戶已關閉日誌記錄也始終希望可用於調試目的的消息。

你肯定不會想了很多的信息發送到跟蹤控制檯因爲它強加性能損失，但一些關鍵信息可能是適當的。

來源

2008-12-31 00:27:18

我傾向於使用Trace（與相關的TraceSwitch）在發佈環境中進行日誌記錄 - 然後對app.config進行快速調整，然後可以給出不同級別的日誌記錄，而無需重新編譯（這可能會使無論如何問題都會消失）或者需要附加一個調試器。尤其是得心應手，只有客戶的機器發生不管出於什麼原因的問題 - 我用這個成功轉儲記錄了一個FTP類的（在舊框架1.1天回），以幫助診斷兩家公司

來源

2008-12-31 11:05:19

跟蹤和調試語句

回答

相關問題