WCF死得不明不白? WCF追蹤助你抽絲剝繭

相信許多人都有WCF很難Debug的印象! 的確,Client透過Proxy Class以非同步呼叫執行於Host程序的程式碼,乍看跟呼叫本地元件沒兩樣,但本質上卻涉及一連串複雜機制,要將Server端或傳輸環節中發生的錯誤詳實地傳到呼叫端本來就不是件簡單的事。

昨天剛好遇上一起RIA Service離奇暴斃案,只知WCF呼叫無疾而終,別無線索,最後還是靠著修改程式看結果變化的土方法才找出傳回結果項目過多的問題。不過,在爬文過程中,意外發現了因先前不夠用功所以遺漏的好東西--WCF Tracing

WCF內建了保留追蹤記錄的功能,我們只需在web.config中加入:

<configuration>
   <system.diagnostics>
      <sources>
            <source name="System.ServiceModel" switchValue="Information, ActivityTracing"
                    propagateActivity="true">
            <listeners>
               <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener"
                   initializeData= "c:\log\Traces.svclog" />
            </listeners>
         </source>
      </sources>
   </system.diagnostics>
</configuration>

就可以將追蹤資料以XML格式寫入Log檔,然後透過Service Trace Viewer Tool檢視WCF運作的細節。以RIA Service暴斃奇案為例:

追蹤資料中明明白白揭示了問題所在:

There was an error while trying to serialize parameter httq://tempuri.org/:GetEntitiesResult. The InnerException message was 'Maximum number of items that can be serialized or deserialized in an object graph is '65536'. Change the object graph or increase the MaxItemsInObjectGraph quota. '.  Please see InnerException for more details.

善用WCF追蹤功能,下回追WCF問題就不用苦無線索想破頭囉! 至於MaxItemsInObjectGraph的問題要如何解決,請收看續集。

歡迎推文分享:
Published 09 July 2010 11:09 AM 由 Jeffrey
Views: 13,631



意見

沒有意見

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<July 2010>
SunMonTueWedThuFriSat
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567
 
RSS
創用 CC 授權條款
【廣告】
twMVC

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication