Dotnet跨應用程式定義域訪問和需要特別注意的地方(WCF訊息通道處於錯誤狀態異常中的一種情況)

今天在做分散式運算原型的時候出現了WCF調用錯誤,錯誤大意是指訊息通道處於錯誤狀態,經過跟蹤調試,發現是由於跨域調用的問題造成的.

問題情境是這樣：用戶端C通過WCF調用遠程服務，該服務S啟用一個新的應用程式定義域AD1，動態載入目標程式集，並執行該程式集中類CL的一個方法M，並將該方法的傳回值（類型為T1）返回用戶端C.這個應用程式定義域AD1雖然與主應用程式定義域都屬於同一進程，但並不能直接相互訪問，必須通過遠程調用來實現，當然，由雩都是同一個進程下，只要參與這個遠程調用的對象都是繼承自MarshalObjectByRef,這種遠程調用並不需要象通常的那樣通過remoting來實現，DotNet會自動處理。 Dotnet採用的是透明代理的方法（類似於我前面關於Spring技術博文中的AOP實現的方法），代理類是動態產生的。一般情況下這沒有什麼問題，但如果將調用目標方法返回的對象直接返回給WCF用戶端，問題就出來了，就會報訊息通道處於錯誤狀態的異常。為什麼會出現這種情況呢，原因如下：由於參與這個過程的類都會產生一個代理類，而且是動態產生的，因此調用方法M返回對象的實際類型並不是T1,而是T1 的一個代理子類TP1，注意，由於TP1是T1 的子類，基於物件導向繼承的原則，父類可以用的地方，子類都可以用，因此編譯時間和運行時都不會出現類型錯誤。一般情況下這也沒有問題，因為你使用T1類型變數是可以訪問該代理對象的，但直接將該傳回值對象作為WCF服務方法的傳回值就有問題了，因為WCF對傳回值進行序列化的時候是針對實際類型的（就是對象執行個體實際的類型,上面的調用中就是TP1),服務端用這個類型序列化沒問題，因為類型TP1是存在的,但到用戶端時，並不能還原序列化回來，因為代理類TP1是動態產生的，只在服務端存在，用戶端並不存在，所以就會報錯。當然，這個錯誤判的有點籠統，害得我調試了半個小時才找到原因（分布式程式調式本身就是個細活)。

找到問題的原因，解決的辦法很簡單，就是重新建立一個傳回型別的執行個體，並將跨域返回的類型的值複製到這個執行個體，然後返回建立的這個執行個體對象即可。

這個錯誤比較隱蔽，主要原因是跨應用程式定義域訪問的代理對象是DotNet動態產生的，而且是不需要程式員去幹預的。

PS:這也是C#中協變和抗變時需要特別注意的地方.

補充：在自己增加WCF宿主服務時，一個連接埠只能被一個應用所有, 如果想在一台機器上啟動多個宿主服務應用，則需進行連接埠層級的分離，路徑和服務名只能在一個應用中做區分。否則會報該地址連接埠監聽已被佔用之類的的錯誤。而且由於一個服務需要建立一個host,因此建議一般情況下還是不要自己做宿主服務，用iis,WAS承載比較好。 

補充(2012-02-08)：跨域調用時參與的類需要從MarshalByRefObject繼承，而這個類最好不要用於WCF通訊參數或傳回值，會發生莫名其妙的序列化錯誤（有時候可以，有時候又不可以，但錯誤率很高）。結論就是用於跨應用程式定義域訪問的參與類不要參與WCF通訊。如果實在要參與，就需要對這種類設定標準合約屬性(DataContractattribute,DateMemberAttribute).就為了調試這個錯誤，浪費了我2個小時有多。感覺這是微軟WCF的一個bug,要麼嘛，你就可以，要麼嘛你就不行，有時候序列化正常，有時候序列化又出錯（出在用戶端代理這邊).