質問

これは解決されました


これは、サービスコールから取得できない契約です。

[DataContract]
public class myInitializationData : ClientInitializationData
{
    [DataMember]
    public Dictionary<string, string> CultureNameLookup { get; set; }
}

これがベースタイプです、

[DataContract]
public class ClientInitializationData
{
    [DataMember]
    public List<IServiceType> ServiceTypes { get; set; }
}

IServiceType インターフェイスです。ワイヤー全体にインターフェイスを送信できないことに気付きました。 EntityFrameworkエンティティがあります、 ServiceType, 、実装 IServiceType インターフェース:

public partial class ServiceType : IServiceType
{
    //...
}

私の目標は送ることです ServiceType ワイヤーを介してエンティティを介して myInitializationData 契約する。

私は飾ることを妨げられます myInitializationData また ClientInitializationData の既知のタイプのクラス ServiceType, 、これらのクラスはシルバーライトプロジェクトに共有(リンク)されているためです。したがって、これらのクラスのいずれかを既知のタイプで飾る場合 ServiceType, 、シルバーライト側はコンパイルに失敗します。

クラスを直接飾る代わりに、私はサービス契約をnecknowtypeとともに飾りました ServiceType:

[ServiceContract]
[ServiceKnownType(typeof(ServiceType))]
public interface IService
{
    [OperationContract]
    myInitializationData InitializeClient();
}

これは機能する必要がありますか?

電話するとき IService.InitializeClient, 、クライアントで次のエラーを受け取ります。

There was an error reading from the pipe: The pipe has been ended. (109, 0x6d).

トレースデバッグを有効にしましたが、クライアントまたはサーバーのトレースでシリアル化の失敗に関するメッセージは見つかりませんでした。

サーバートレース:

  • チャンネルがこれまでにメッセージを受信します(アクション: http://tempuri.org/iservice/initializeclient)
  • 宛先:実行(iService.Initializeclient)
  • from:execute(iService.Initializeclient)
  • チャネルを介してメッセージを送信します(アクション: http://tempuri.org/iservice/initializeclientResponse)
  • 警告障害System.ServiceModel.Channels.ServersessionPreamBleconnectionReader+ServerFramingDuplexSessionChannel
  • 警告障害System.ServiceModel.Channels.ServiceChannel
  • 操作に返信すると例外が投げられました(ObjectContextインスタンスは処分されており、接続を必要とする操作には使用できなくなりました。)

クライアントトレース:

  • チャネルを介してメッセージを送信します(アクション: http://tempuri.org/iservice/initializeclient)
  • 例外を投げる(パイプからのエラー読み取りがありました。パイプが終了しました。 (109、0x6d)。)

私が選択した場合 ServiceTypes のプロパティ ClientInitializationData DataContract、このエラーは消えます。したがって、これはシリアル化の問題でなければならないと思います。インターフェイスと既知のタイプですが、WCFはトレースにシリアル化の問題があると主張していません。この場合、トレースが何を意味するのかわかりません。


解決

これは既知のタイプの問題ではありませんでした。それは、エンティティコンテキストで自発的に有効になっているレイジーロードの結果でした。 ServiceType タイプ。

過度のメッセージやバッファサイズがトレースで違反されていることについては言及されていませんが(クライアント側またはサーバー側のいずれかで)、EFコンテキストでのレイジーロードの有効化により、DataContractSerializerがEFをトリガーしてフェッチすると仮定する必要があります。 多くの レコードの場合、ワイヤーに大きなグラフがある(試行された)ことができました。サーバー側は、メッセージ書き込み中にチャネルに単純に(そして曖昧に)障害を抱えていました。

EFコンテキストで障害のある状態へのレイジーロードを返すことは、この問題を解決しました。

役に立ちましたか?

解決

これは既知のタイプの問題ではありませんでした。これは、ServiceTypeタイプを定義するエンティティコンテキストで自発的に有効になっているレイジーロードの結果でした。

過度のメッセージやバッファサイズがトレースで違反されていることについては言及されていませんが(クライアント側またはサーバー側のいずれかで)、EFコンテキストでのレイジーロードの有効化により、DataContractSerializerがEFをトリガーして多くのレコードを取得したと仮定する必要があります。 、これにより、ワイヤに大きなグラフがあります(試行されました)。サーバー側は、メッセージ書き込み中にチャネルに単純に(そして曖昧に)障害を抱えていました。

EFコンテキストで障害のある状態へのレイジーロードを返すことは、この問題を解決しました。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top