tags:

views:

331

answers:

2

Looking for some collective wisdom. Here is the situation. This is using Visual Studio 2008.

  1. We have a simple WCF contract exposing the following method:

    DataSet ExecuteQuery (out string someStuff);
    
  2. This method is implemented as:

    public DataSet ExecuteQuery (out string someStuff)
    {
        someStuff = "abc";
        return new DataSet(); // simplified
    }
    
  3. Client side proxy is generated by svcutil, and appears to be correct.

Problem:

someStuff is always null on the client side.

Observations:

  1. Same problem appears on our build machine.
  2. Returning a string instead of DataSet makes client proxy receive proper value of out parameter:

    public string ExecuteQuery(out string someStuff) ...
    
  3. Removing the client proxy completely and regenerating it doesn't help.

  4. Client definitely receives both DataSet and the "out" string, as seen in its trace log:

<ExecuteQueryResponse xmlns="http://tempuri.org/"&gt; <ExecuteQueryResult> <xs:schema id="NewDataSet" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"> <xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:UseCurrentLocale="true"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"></xs:choice> </xs:complexType> </xs:element> </xs:schema> <diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1"></diffgr:diffgram> </ExecuteQueryResult> <someStuff>abc</someStuff> </ExecuteQueryResponse>

  1. Here is how the client proxy generates the code:

    [System.ServiceModel.OperationContractAttribute 
    (Action="http://tempuri.org/IQueryContract/ExecuteQuery", 
    ReplyAction="http://tempuri.org/IQueryContract/ExecuteQueryResponse")]
    [System.ServiceModel.XmlSerializerFormatAttribute()]
    System.Data.DataSet ExecuteQuery(out string someStuff);
    
  2. We use netTcpBinding

Do we need to do anything special in order to return DataSet and out parameters? Anyone has come across anything similar?

Thanks!!!!

A: 

I had [XmlSerializerFormat] at the top of my contract interface. Removing it fixed the problem, as WCF starts using the default [DataSerializerFormat]. Thanks Darin for point it out.

Still not sure why XmlSerializerFormat wouldn't work.

Daniel
A: 

WCF, as defined by SOA, must not transport an object (state and behavior), only the state and strucuture of an object. BinaryFormatter, and SoapFormatter are inadequate for SOA because: 1) Requires both ends to share type 2) cannot be used for contracts 3) both formatters require streams

DataContractSerializer only shares types not contracts. It adds support for XML readers and writers, only captures state according to the schema, and deos not support IFormatter.

All of which I took from my WCF course that I took from Juval Lowry :)

Richard

codputer