views:

1615

answers:

1

I have a simple WCF Service that needs to handle large datastreams, so I have the a lot of the config values bumped up above the defaults. I've recently been moving all of my code into a new, restructured solution, and I just moved over the service. However, when I try to generate a client proxy (using either WCFTestClient.exe or "Add Service Reference" in VS2008, the values in the client proxy config do not match what I have setup for the service.

This is the server config - notice the increased values for maxBufferSize, maxReceivedMessageSize, maxStringContentLength and MaxArrayLength

  <system.serviceModel>
    <bindings>    
      <basicHttpBinding>
        <binding name="default" maxBufferSize="5000000" maxReceivedMessageSize="5000000">
          <readerQuotas maxStringContentLength="5000000" maxArrayLength="5000000" />
          <!-- turn this setting on to require SSL/https -->
          <!-- <security mode="Transport" /> -->
        </binding>       
      </basicHttpBinding>
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="Consent.Service.SubjectConsentServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service behaviorConfiguration="Consent.Service.SubjectConsentServiceBehavior"
        name="Consent.Service.SubjectConsentService">
        <endpoint address="" binding="basicHttpBinding" bindingConfiguration="default"
          contract="Consent.Service.ISubjectConsentService">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
  </system.serviceModel>

Here is the proxy generated by VS2008 with "Add Service Reference"

<system.serviceModel>
    <bindings>
        <basicHttpBinding>
            <binding name="BasicHttpBinding_ISubjectConsentService" closeTimeout="00:01:00"
                openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                useDefaultWebProxy="true">
                <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                    maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                <security mode="None">
                    <transport clientCredentialType="None" proxyCredentialType="None"
                        realm="" />
                    <message clientCredentialType="UserName" algorithmSuite="Default" />
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <client>
        <endpoint address="http://server/Consent/services/SubjectConsent.svc"
            binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ISubjectConsentService"
            contract="ServiceReference1.ISubjectConsentService" name="BasicHttpBinding_ISubjectConsentService" />
    </client>
</system.serviceModel>

The client proxy has those 4 values set to the default.

Any ideas why the client is using the default values?

+2  A: 

The values that are set in the server's config file are not exposed as part of the web service's metadata (because they relate to the transport layer, not the service itself), so a client (or, in this case, the "Add Service Reference" function) has no way to find out about them automatically. (All "Add Service Reference" does is ask for the WSDL and generate corresponding classes; it does not have access to transport-related settings in the config file.)

As such, you'll need to override them on both the client and server.

Eric Rosenberger
Ugh, I think you're right. I could swear that I didn't have this problem in the past, but apparently I must have manually updated the config to get around it.
Jason