Today I was busy setting up a WCF service for some interoperabillity with another system. When posting a chunk of XML, I got a nice exception stating: "There was an error deserializing the object of type . 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.". That's nice, usually these kind of small issues are solved in no-time. Well, think again...

Stackoverflow

Google led me to to a couple (this and this) of stackoverflow discussions/questions. The first one didn't make much sense since the guy replying said it was all "correct behavior" but not really giving a solution on how to fix it. Anyway, no matter how many times or where I changed the value of maxStringContentLength, it always seemed to pick up the deafult value.

Debugging!

After a morning of messing about with config files and trying every possible configuration combination, I discovered that using the "name" attribute doesn't always make things better. The first problem I ran into was when trying to open my config file in the WCF config editor tool. It came nagging me about the "name" attribute in my serviceBehaviour being empty. Entering a name and pointing my service to that particular name left the WSDL publishing defunct. I could only get it working again by removing the name (not the entire attribute, just the value!)... Pretty strange... Why wouldn't it take those names?

Some more dabbling brought me to that last post I mentioned. He claimed his problem had gone away by removing the "name" attribute from the binding configuration and removing the reference to a specific bindingConfiguration from the endpoint. After reading through the answer and the comments a couple of times, it seems to be boiling down to the following:
when not supplying a "name" attribute in the binding configuration or behavior configuration, the element is being interpreted as default. Apparently, when you do not supply the complete name -including the namespace- of the service in it's configuration, it's not being picked up. As a result, your endpoint configuration is also ignored and hence the reverting to default settings.

So what can do to get rid of this problem is either removing the name of the configuration (binding & behavior) so that these will be used as default, or name your service with it's fully qualified name.