SOAP/MTOM: Problems with VS-generated proxy class and handling PDF attachments

Question

Background info: building a webservice-consuming client in C#. Used svcutil to auto-generate the proxy class. The web service is set up to send PDF attachments via MTOM, and when I use the API call from the proxy to try to do so, I get the following error:

Client found response content type of 'multipart/related; boundary="MIMEBoundaryurn_uuid_5D7E9AC12266BFFBDB1370543444063"; start-info="text/xml"; type="text/xml"; start="<0.urn:uuid:5D7E9AC12266BFFBDB1370543444064@apache.org>"', but expected 'text/xml'.

...which I've found means that the client isn't properly configured for MTOM. Okay, cool, there are some examples of how to change the config to make it so. Here's where I'm tripping up, though--all of the examples that I've found so far have the config file mapped differently than how mine is set up. The examples are set up with two items in the system.serviceModel section, one for the bindings and one for the client endpoint, which contains the endpoint address. My auto-generated config plops the address into the applicationSettings, and, well, I'm confused. :( Here they are, side by side:

Examples:

<?xml version="1.0"?>
<configuration>
  <system.serviceModel>
    <bindings>
      <wsHttpBinding>
        <binding name="WSHttpBinding_IUpload" messageEncoding="Mtom"/>
      </wsHttpBinding>
    </bindings>
    <client>
      <endpoint address="http://localhost/ServiceModelSamples/service.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IUpload" contract="IUpload">
      </endpoint>
    </client>
  </system.serviceModel>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup></configuration>

Mine:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=----------------" >
          <section name="TWS.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=----------------" requirePermission="false" />
        </sectionGroup>
      </configSections>
      <applicationSettings>
        <TWS.Properties.Settings>
          <setting name="TWS_WebService_WsApiService" serializeAs="String">
            <value>https://www.<redacted>.com/services/WsApiService/</value>
          </setting>
        </TWS.Properties.Settings>
      </applicationSettings>
    </configuration>

Here's how the API call itself is set up in the proxy class:

[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://localhost:8080/getStiDoc", RequestNamespace="http://www.<redacted>.com/ws/schemas", ResponseNamespace="http://www.<redacted>.com/ws/schemas", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
        [return: System.Xml.Serialization.XmlElementAttribute("doc", Form=System.Xml.Schema.XmlSchemaForm.Unqualified, DataType="base64Binary", IsNullable=true)]
        public byte[] getDoc([System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified, IsNullable=true)] string username, [System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified, DataType="integer", IsNullable=true)] string id) {
            object[] results = this.Invoke("getDoc", new object[] {
                        username,
                        id});
            return ((byte[])(results[0]));
        }

My question is this: With how my config file is set up, how should I add the appropriate bindings to ensure that it looks for MTOM instead of base64 binary?

Answer 1

Found the answer on my own, finally. In order to get the proxy class set up properly (i.e. in WCF-compliant form), I had to use svcutil via command line to convert the WSDL to the proxy class. After I did that, I was able to set the message binding to MTOM. I'm still having trouble getting it to authenticate with the certificate, but that's a smaller issue.