WCF-Client-Probleme erkennen ServiceKnownTypes?

Zur Vermeidung der Abschreckung von Ihrem service-code, der die bekannten Typen in web.config des service:

<system.runtime.serialization>
    <dataContractSerializer>
        <declaredTypes>
            <add type="SomeNs.BaseClassZ, SomeAssembly">
                <knownType type="SomeNs.SubClassA, SomeAssembly" />
                <knownType type="SomeNs.SubClassB, SomeAssembly" />
            </add>
        </declaredTypes>
    </dataContractSerializer>
</system.runtime.serialization>

Wenn Sie wollen, es zu tun, indem Sie code, den Sie benötigen, um dieses Attribut auf die service-Schnittstelle und nicht auf die operation-Methode, aber ich würde es vorziehen, den deklarativen Ansatz:

[ServiceContract]
[ServiceKnownType(typeof(SubClassA))]
[ServiceKnownType(typeof(SubClassB))]
public interface IFoo
{
    [OperationContract]
    BaseClassZ GetObject();
}

UPDATE:

Habe ich eine Beispiel-Projekt, welche die Verwendung der web.config zum konfigurieren der bekannten Typen, das ist mein bevorzugter Ansatz. Und ein weiterer Beispiel-Projekt demonstriert der zweite Ansatz.

UPDATE 2:

Nach einem Blick auf die aktualisierte code mit dem Silverlight-client-Anwendung bemerken wir die folgende definition:

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(ConfigurationName="ServiceReference1.IService1")]
public interface IService1 {

    [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action="http://tempuri.org/IService1/GetMany", ReplyAction="http://tempuri.org/IService1/GetManyResponse")]
    System.IAsyncResult BeginGetMany(System.AsyncCallback callback, object asyncState);

    System.Collections.ObjectModel.ObservableCollection<MyCommonLib.BaseClassZ> EndGetMany(System.IAsyncResult result);

    [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action="http://tempuri.org/IService1/GetSingle", ReplyAction="http://tempuri.org/IService1/GetSingleResponse")]
    [System.ServiceModel.ServiceKnownTypeAttribute(typeof(MyCommonLib.SubClassA))]
    [System.ServiceModel.ServiceKnownTypeAttribute(typeof(MyCommonLib.SubClassB))]
    System.IAsyncResult BeginGetSingle(System.AsyncCallback callback, object asyncState);

    MyCommonLib.BaseClassZ EndGetSingle(System.IAsyncResult result);
}

Beachten Sie, wie die BeginGetSingle - Methode enthält den bekannten type-Attribute während der BeginGetMany Methode nicht. In der Tat werden diese Attribute sollten sein gelegt auf die service-definition, so dass die Klasse sieht wie folgt aus.

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(ConfigurationName="ServiceReference1.IService1")]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(MyCommonLib.SubClassA))]
[System.ServiceModel.ServiceKnownTypeAttribute(typeof(MyCommonLib.SubClassB))]
public interface IService1
{
    [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action="http://tempuri.org/IService1/GetMany", ReplyAction="http://tempuri.org/IService1/GetManyResponse")]
    System.IAsyncResult BeginGetMany(System.AsyncCallback callback, object asyncState);

    System.Collections.ObjectModel.ObservableCollection<MyCommonLib.BaseClassZ> EndGetMany(System.IAsyncResult result);

    [System.ServiceModel.OperationContractAttribute(AsyncPattern=true, Action="http://tempuri.org/IService1/GetSingle", ReplyAction="http://tempuri.org/IService1/GetSingleResponse")]
    System.IAsyncResult BeginGetSingle(System.AsyncCallback callback, object asyncState);

    MyCommonLib.BaseClassZ EndGetSingle(System.IAsyncResult result);
}

Dies ist eine automatisch generierte Klasse, es könnte ein bug in der SLsvcUtil.exe und svcutil.exe, da es zeigt das gleiche Verhalten. Setzen die bekannten type-Attribute auf Ihrer richtigen Stelle löst das problem. Das problem ist, dass diese Klasse ist eine automatisch generierte durch ein Werkzeug, und wenn Sie versuchen, sich zu regenerieren es von der WSDL wird es mess up wieder.

So scheint es, dass, wenn Sie die folgende service-definition:

[ServiceContract]
[ServiceKnownType(typeof(SubClassA))]
[ServiceKnownType(typeof(SubClassB))]
public interface IService1
{
    [OperationContract]
    BaseClassZ[] GetMany();

    [OperationContract]
    BaseClassZ GetSingle();
}

Und die 3 Daten-Verträge, die hier geteilt werden zwischen dem client und dem server beim importieren der definition des Dienstes, die Methode gibt eine collection zurück, erhalten nicht die richtigen bekannten type-Attribute in den generierten client-proxy. Vielleicht ist das by design.

InformationsquelleAutor Darin Dimitrov

Es ist ein weiterer Weg, dies zu tun. Anstatt mit "add service reference" geben Sie den code der proxy-Klassen. Es ist etwas mehr Codierung zunächst aber gibt Ihnen viel mehr stabile und robuste Lösung. Wir haben festgestellt, dass das spart uns Zeit in der langen run.

Finden Sie unter: http://www.dnrtv.com/default.aspx?showNum=122

Hinweis: dies funktioniert nur, wenn Sie die Kontrolle über den server und den client.

InformationsquelleAutor Shiraz Bhaiji