相信許多人都有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的問題要如何解決,請收看續集。


Comments

Be the first to post a comment

Post a comment


71 + 17 =