1

I have a hand-written WSDL, along with a few XSD files. A .NET client needs to load an XML document from disk and send its contents as part of the SOAP message. From what I've been reading I think I need to influence svcutil.exe or wsdl.exe to treat this part of the SOAP message as an XmlElement, rather than trying to create types for it.

Is the correct way to do this to specify part of the message as an <xs:any> in the schema?

Is there another way that would allow me to properly specify the message in the schema without using <xs:any>?

I have control over the WSDL and the Java service implementation, and somewhat less control over the WCF client.

Here's a sample message from the WSDL:

<wsdl:message name="TransmitFoo">
  <wsdl:part name="body" element="someprefix:TransmitFooRequest"/>
</wsdl:message>
<wsdl:portType...>
  <wsdl:operation name="TransmitFoo">
    <wsdl:input message="tns:TransmitFoo">
  </wsdl:operation>
</wsdl:portType>

The definition of TransmitFooRequest from the schema is as follows:

<xs:element name="TransmitFooRequest">
  <xs:complexType>
    <xs:all>
      <xs:element name="someValue" type="xs:string"/>
      <xs:element ref="someprefix:bar" />
    </xs:all>
  </xs:complexType>
</xs:element>

<someprefix:bar> is defined in the schema. This is the part that is loaded from disk. I'd like the generated WCF proxy class to have a method signature kind of like this:

TransmitFoo(String someValue, XmlElement bar)

I have seen an answer for a similar requirement where the WSDL is generated from the WCF server; I am doing the opposite, generating WCF client stubs from a WSDL.

I realize the client could also build the SOAP message and headers completely manually, as in another answer, but re-implementing SOAP is something I'd like to avoid.

Community
  • 1
  • 1
MZS
  • 573
  • 4
  • 12
  • Interesting question! Does [using the XmlSerializer](http://msdn.microsoft.com/en-us/library/ms733901.aspx) for that method instead of the DataContractSerializer give you the flexibility you'd need to build a set of types that serialise correctly to a `bar`? If so, you might be able to use those types in your proxy rather than `XmlElement`. Something like `TransmitFoo(string someValue, Bar bar)` where `Bar` and its members have the appropriate XML serialisation attributes. – anton.burger Jun 22 '11 at 22:42
  • I suppose in that case I'd have to modify the proxy classes generated by the tools. I'd like to avoid that if I can, but it might be an option. However the on-disk XML chunks are encrypted and signed, and it took some doing to get it working interoperably, so I'd rather not throw it out and start from scratch from XmlSerializer types. – MZS Jun 23 '11 at 01:39
  • @shambulator Seems like a custom IClientMessageFormatter might be the way to go: http://stackoverflow.com/questions/3067650/how-to-ignore-timezone-of-datetime-in-net-wcf-client and http://msdn.microsoft.com/en-us/library/ms730107%28v=VS.90%29.aspx – MZS Jun 23 '11 at 04:34
  • @shambulator I think you were right I just wasn't clever enough to realize it. The proxy classes are defined as partial classes in the generated file, so in another file I can make the class implement IXmlSerializable and override ReadXml()/WriteXml() to do what I need. Thanks! – MZS Jun 23 '11 at 14:54

0 Answers0