擴展．ＮＥＴ ２．０的跟蹤系統

摘 要：微軟公司隨VISUAL STUDIO 2005 發布了.NET 2.0，該系統較.NET 1.1增加了大量實用方便的功能和新特性，跟蹤系統部分同樣大大增強了功能。如何用好這些功能，特別是定制這些功能，使之更好地為我們服務，成為我們的當前任務。本文將探討一下這方面的問題。

關鍵詞： TraceSource類 Switch類 StopWatch精確度 堆棧信息 線程 進程 遠程過程調用

一、跟蹤系統概念介紹

在.NET 2.0中，除了用來在程序中輸出調試和跟蹤信息的Debug類和Trace類外，還有TraceSource類。TraceSource類是.NET 2.0新添加的類，微軟公司建議在新開發的程序中使用TraceSource類來產生調試跟蹤信息。調試開關用來過濾信息的輸出，跟蹤偵聽器（TraceListener）類用來向外界真正輸出調試信息。所有類的參數都可通過程序配置文件進行設置，而不需要重新編譯程序，修改程序配置信息即可改變該程序的調試跟蹤信息輸出的行為。

跟蹤偵聽器用來收集、存儲和路由跟蹤消息，是真正對外輸出日志信息的類對象。系統提供的跟蹤偵聽器往往不能滿足我們在實際應用程序中的需要。例如，在無人職守環境下，服務程序的執行日志需要輸出到能夠自動切換的具有固定大小的日志文件中，而以上系統提供的跟蹤偵聽器均無法完成該任務。此時需要制定自己的跟蹤偵聽器。在使用Debug、Trace和TraceSource對象時，系統可根據配置信息為以上對象生成跟蹤偵聽器。如果沒有配置信息，系統將會為Debug和Trace生成缺省的跟蹤偵聽器（DefoultTraceListener），該偵聽器將消息發送到調試器的消息窗口（Visual studio的debug窗口）。系統還提供了EventLogTraceListener、ConsoleTraceListener、TextWriteTraceListener、DelimitedListTraceListener和XmlWriterTraceListener跟蹤偵聽器。Debug、Trace和TraceSource所使用的跟蹤偵聽器被放在各自的Listeners屬性中，可通過編程來訪問和維護該偵聽器列表。

所有的跟蹤偵聽器均派生自TraceListener類，該類是抽象類，在用戶制定的派生類中，需要重載和消息輸出有關的函數包括：TraceData()，TraceEvent()，Write()，WriteLine()，Fail()。這些函數負責接受其它程序部件調用，輸出跟蹤消息。

TraceListener類還實現了IDisposable接口，該接口中的Dispose()和Finalize()被用來關閉和釋放資源。

完成自定義跟蹤偵聽器后，可將該偵聽器放在單獨的動態鏈接庫中，方便其它程序共享該組件。實例化該偵聽器，可通過配置文件來完成，也可通過編程，手工實例化偵聽器對象，再將偵聽器添加到TraceSource或Trace的Listeners屬性中。

二、定義自己的跟蹤開關類

跟蹤開關用于啟用、禁用和篩選跟蹤輸出。它們是存在于代碼中的對象，可以通過.config文件從外部進行配置。.NET Framework中提供了三種類型的跟蹤開關：BooleanSwitch類、TraceSwitch類和SourceSwitch類。BooleanSwitch類用作切換開關，可啟用或禁用各種跟蹤語句。TraceSwitch和SourceSwitch類用于為特定的跟蹤級別啟用跟蹤開關，以便顯示為該級別及其下的所有級別指定的Trace或TraceSource消息。如果禁用此開關，則不會顯示跟蹤消息。

跟蹤開關作用于TraceListener類，通過跟蹤偵聽器的Filter屬性，可訪問該偵聽器的跟蹤開關對象。當系統提供的跟蹤開關類不能滿足程序要求時，需要開發用戶自己的跟蹤開關。所有的跟蹤開關對象都派生自Switch類，派生類中必須實現SwitchSetting方法和OnValueChanged方法。Switch類的Value屬性用來設置或返回用來過濾消息的值的字符串。對Value屬性的賦值將會調用OnValueChanged方法，在該方法中，需要將字符串的Value值轉換成int型的值，用來設置SwitchSetting屬性。

同用戶自定義跟蹤偵聽器一樣，建議將用戶自定義跟蹤開關放到單獨的動態鏈接庫中，方便不同的應用程序共享該組件。同樣，可通過配置文件，為跟蹤偵聽器對象生成對應的跟蹤開關對象。

三、用StopWatch來精確測量代碼執行的時間

通常，我們根據經驗，測量一段代碼的執行時間，是在代碼的開始位置記錄當前的系統時間，在代碼結束時，也記錄一次系統當前時間，再比較這兩個時間，獲得這兩個時間之間的差別，精確到毫秒。

但本方法存在以下問題：首先是精度不夠。當代碼執行時間在毫秒以下時，無法測量時間。其次，系統的當前時間的更新間隔并不能達到毫秒級，而是1/18秒。這樣，以上方法的實際測量精度是1/18秒，精度太低。

為解決以上問題，.NET Framework 2.0中提供了Stopwatch類。該類提供了一組屬性和方法，能夠精確測量代碼的執行時間。Stopwatch實例可以測量一個時間間隔的運行時間，也可以測量多個時間間隔的總運行時間。在典型的Stopwatch方案中，先調用Start方法，然后調用Stop方法，最后使用Elapsed屬性檢查運行時間。

Stopwatch類的Frequency屬性是以每秒刻度數表示的計時器頻率，ElapsedTicks屬性是獲取當前實例測量得出的總運行時間（用計時器刻度表示）。其中計時器刻度是指Frequency分之一秒的時間間隔。當然，也可通過Elapsed方法獲得TimeStamp對象，來獲得100毫微秒為單位的計時器刻度（Ticks）時間。

四、利用StackTrace獲取函數調用堆棧信息

在設計應用程序的日志系統時，打印函數的進入和退出記錄，是經常需要使用的功能。此時獲取當前函數的名稱以及所在類的名稱，甚至函數調用堆棧信息，是必須作為日志信息輸出的內容。如何實現以上功能呢？

.NET Framework的StackTrace類，屬性以逆向時間順序列出了方法調用，即描述了最近的方法調用，還為堆棧上的每個方法調用都列出一行堆棧跟蹤信息。如果在編譯時生成了調試符號，調試符號包含在構造StackFrame和StackTrace對象時使用的文件、方法名、行號和列信息這些數據中的大部分。但是，由于優化期間發生的代碼轉換，StackTrace屬性報告的方法調用可能沒有預期的多。

StackTrace是一個包含StackFrame對象的堆棧，堆棧最上面的是最近發生的函數調用信息。StakFrame對象中包含函數名稱，文件名稱，行號，函數參數等信息。應用程序可在需要的地方生成StackTrace對象，然后遍歷該堆棧，以輸出程序執行路徑相關的跟蹤消息。

五、利用CorrelationManager對象在不同線程和進程間保持調用線索和相關數據

在分布式應用程序中，一個方法的執行，會延續到另外進程的方法中，如何關聯不同進程中的方法執行線索，成為日志系統設計時的一個棘手問題。

.NET framework為我們提供了一個方便的解決方案——CorrelationManager對象。該對象用來關聯同屬于某個邏輯事務的多個跟蹤，可以使用唯一操作的標識對通過單個邏輯操作生成的跟蹤進行標記，以將其與通過其他邏輯操作生成的跟蹤區分開來。例如，在基于報文處理的應用程序中，可利用此功能，通過以不同的報文號對操作進行標記，以區分和關聯不同報文在不同進程和函數中產生的日志信息。

邏輯操作也可以嵌套。LogicalOperationStack屬性公開嵌套的邏輯操作標識的堆棧。對StartLogicalOperation方法的每個調用都會將一個新的邏輯操作標識壓入堆棧。對StopLogicalOperation方法的每個調用都會從堆棧中彈出一個邏輯操作標識。邏輯操作標識是對象。

六、截獲和記錄遠程過程調用

在進行遠程過程調用時，函數調用方和函數被調用方都需要對該過程進行記錄，該功能是日志系統應該具備的基本功能。要實現自動記錄該過程，顯然需要截獲所有的遠程過程調用。

在客戶端，有兩種方法能夠截獲對遠程對象的方法的調用。第一種方法，使用用戶制定的RealProxy類。在創建遠程對象的本地代理類時，直接創建用戶制定的RealProxy對象，再用RemotingServices對象的Connect方法創建一個系統提供的RealProxy對象。當用戶調用遠程對象的方法時，調用請求被轉給了用戶定制RealProxy的Invoke方法，在該方法中，可加入跟蹤消息輸出代碼，輸出方法調用的詳細信息，如：遠程對象名稱、方法名稱、參數值等。在用戶制定的RealProxy中，使用函數調用的消息數據，調用實際的RealProxy對象的對應函數，再將返回的值封裝成ReturnMessage對象，返回給實際調用函數。在退出Invoke方法前，還可向日志系統輸出函數調用返回值，或函數調用出錯的詳細信息，遠程過程調用執行時間等信息。第二種方法是制定ClientChannelSink類和ClientChannelSinkProvider類。在生成新的客戶端通道時，由用戶制定的ClientChannelSinkProvider類對象來生成ClientChannelSink類，并將其掛接到客戶端的Remote.NET體系中的客戶端的信道接收鏈的插接點上。這樣在客戶制定的ClientChannelSink的類對象的ProcessMessage方法中，可添加代碼，檢查每次函數調用的詳細數據，并輸出到日志系統中。同樣，也可在函數調用返回時，打印函數返回結果的詳細信息到日志系統中。

在服務端，也可采用同客戶端類似的處理方式。生成用戶定制的ServerChannelSink類和ServerChannelSinkProvider類，在ServerChannelSink類的ProcessMessage方法中，輸出日志信息。

七、捕獲未被處理的異常

在程序執行過程中，需要經常檢查代碼執行的結果，特別是要注意捕捉適當的異常。但總還是有未被捕捉到的異常被拋出，使程序被非正常終止。將所有的異常都捕捉到，并詳細記錄這些異常的相關數據，成為了日志系統應該具有的功能。

在應用程序所在域中，有一個UnhandledException事件，該事件是在應用程序當前域中出現了未被捕獲并處理的異常時被觸發。我們可以在應用程序所在的域對象上，通過處理UnhandledException事件，打印未處理異常的詳細信息到日志系統中，為最終處理這些異常提供方便。

參考文獻：

［1］Andrew Haigh著.賈愛霞譯.面向對象的分析與設計.北京：機械工業出版社，2003.

［2］黃忠成.Framework的設計與應用：基于Windows Forms的應用開發實踐.電子工業出版社，2006.

［3］Chappell，D著.榮耀譯..NET大局觀.電子工業出版社，2006.