Wednesday, March 16, 2011

Reader Quotas for WCF Services in SharePoint 2010

Creating a WCF service in SharePoint 2010 is relatively easy.  The first thing to do is follow the basic steps in Microsoft's post "Creating a Custom WCF Service in SharePoint Foundation".  This will give you a nice starting point for your Service as long as you don't need to need to change any of the Binding information.

Try sending a 70k file to your nice new WCF service.  Oops  error!

The remote server returned an unexpected response: (400) Bad Request.*

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.

Ok no problem.  If you have done any WCF Service code in the past you probably know that you need to alter some of the binding information to increase the message size and or change the attributes for the readerQuotas no big deal right? 


SharePoint 2010 has this great new hosting ability MultipleBaseAddressBasicHttpBindingServiceHostFactory and it does all the work required to set up the end points and bindings. You don't need to do create a web.config file or write any WCF service code.

So right about now you should be asking yourself "Self, how do I change the binding information then?".
Well after hunting around for the better part of a day I found a couple of post that talked about using the SPWebService.ContentService to programmatic change the binding information.
For example:

But no where do any of the post talk about where do I run this code.  Wouldn't make sense to run it on the client, although you do need to make some changes on the client side as well.  And running it as a Event Receiver when the feature for the WCF Service is installed did not work for me ether.

So what next???
Well I finally came across a comment on one of the MSDN pages by Dan Mayernik.

First, to update the configuration for a custom WCF service -add a WebApplication level feature with nothing more then a feature receiver. The receiver should override "FeatureInstalled" as follows:

Obviously, the values listed above are the extreme cases and should be set according to what your service will need. Also, the key for the indexer used for the WcfServiceSettings collection is the name of your service file. If you place the file in a subdirectory -do not include the subdirectory name as part of the key.

Thus, if your service is deployed to the ISAPI directory under:

the key for the WcfServiceSettings collection would be:

CAUTION: The key, as stated above, is case sensitive. The key should be all lowercase.

Thanks goes to Dan he saved me from loosing any more of my hair (this week)