WCF services - Keep your system healthy with automated tests

If you are finally able to "call" your webservice, you may run into the following error message:

"The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 501, position 22."

Running into this you may ask yourself these questions

  1. What string content?
  2. Where is there a quota on a string length?
  3. XML data? WTF?
  4. Where does this come from?
    Is it me or Visual Studio or WCF or my laptop?
  5. Should I do a reboot?

A reboot is always a best guess!
Give your machine a reboot now and I wait here in the meantime.


The web service tries to send us back more than 8 kbytes. That is pretty small, if you compare that to your current download bandwidth, but someone decided that this is your default setting as a client. If you as a client (consumer of webservice) receive more than 8kbytes, WCF will reject it.
Now what?


Because WCF relies heavily on configuration files in XML Winking smile (which is good and bad), we start by looking into the application configuration file again (app.config)

<?xml version="1.0" encoding="utf-8" ?>
                <binding name="countrySoap" 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"
                    <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" />
                <binding name="countrySoap12">
                    <textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
                        messageVersion="Soap12" writeEncoding="utf-8">
                        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                            maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                    <httpTransport manualAddressing="false" maxBufferPoolSize="524288"
                        maxReceivedMessageSize="65536" allowCookies="false" authenticationScheme="Anonymous"
                        bypassProxyOnLocal="false" decompressionEnabled="true" hostNameComparisonMode="StrongWildcard"
                        keepAliveEnabled="true" maxBufferSize="65536" proxyAuthenticationScheme="Anonymous"
                        realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"
                        useDefaultWebProxy="true" />
            <endpoint address="http://www.webservicex.net/country.asmx" binding="basicHttpBinding"
                bindingConfiguration="countrySoap" contract="ServiceReference1.countrySoap"
                name="countrySoap" />
            <endpoint address="http://www.webservicex.net/country.asmx" binding="customBinding"
                bindingConfiguration="countrySoap12" contract="ServiceReference1.countrySoap"
                name="countrySoap12" />

Figure: This app.config was created by doing: "Add Service Reference"

Increasing the "max string length quota" fixes this problem.





  1. How can we make sure this won't happen again?
  2. How can we make sure we pick the right "max string length deserialization" quota any way?

My best answer to those questions is: "Tests"
Tests FTW! (aka Tests will cover your arse)

Write an automated test that calls this webservice every morning.
That helps to verify immediately:

  1. The webservice is alive
  2. The webservice provider didn't change the interface or other settings (address, binding or contract)
  3. The webservice call is still working with my current client quotas


BTW: Make sure to check out our Rules to better testing

No comments:

Post a Comment

Latest Posts

Popular Posts