Code First .NET Web Service uses soap encoding - how can this be prevented?

Question

How would one configure asp.net / asmx to not use soap encoding at all when generating wsdls from a .NET interface? In short, a .NET SOAP Web Service is producing a wsdl that includes soap encoding. For example:

<s:schema targetNamespace="http://tempuri.org/AbstractTypes"&gt;
  <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
  <s:complexType name="StringArray">
    <s:complexContent mixed="false">
      <s:restriction base="soapenc:Array">
        <s:sequence>
          <s:element minOccurs="0" maxOccurs="unbounded" name="String" type="s:string" />
        </s:sequence>
      </s:restriction>
    </s:complexContent>
  </s:complexType>
</s:schema>

This fails to parse with wsdl2java in CXF, a JAX-WS implementation due to the soapenc:Array bit. The fix is to change the above xml to:

<s:schema targetNamespace="http://tempuri.org/AbstractTypes"&gt;
  <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
  <s:complexType name="StringArray">
        <s:sequence>
          <s:element minOccurs="0" maxOccurs="unbounded" name="String" type="s:string" />
        </s:sequence>
  </s:complexType>
</s:schema>

Answer 1

This is an issue that is 6 of one, 12/2 for the other - wsdl2java doesn't properly support any complex types the way Microsoft's WSDL implementation thinks it should.

The discussion on whether this is Java or MS's fault is kinda pointless.

Unfortunately there are very few implementations of SOAP that handle anything but primitive types, so while Microsoft Web Services look great for interopability on the surface they actually only really work with Microsoft's proxys.

For your workaround you have a couple of options:

1. Stick to primitive .Net types - basically value types + string. No arrays, lists or anything with a complex serialisation.

2. Write your own HttpHandler to return Xml in a format Java can handle - I've actually done something like this when dealing with Flex/ActionScript (which has the same problem).

3. Go with a different format - IMHO the majority of the web is moving away from SOAP to REST style services.

Of those (1) is the easiest, but also the most clunky. You end up with hacks like a WDSL described SOAP method that returns a string, but that string is actually encoded XML that the consuming Java can parse. Yuk.

You always get fun stuff like this when working across platforms :-(