cog logo pinched from riscos.org.uk

not very helpful at all!

Message size. If you're returning lists of items or rich data types, there's a good chance you're going to run into the default size limits on WCF messages. See below for more information on how to change the message sizes.

If you're returning lists of items or rich data types, there's a good chance you're going to run into the default size limits on WCF messages. See below for more information on how to change the message sizes. Proxies. When using an ORM such as NHibernate, it's possible you'll run into these. NHibernate likes to subclass your data classes and replace lists and things with its own persistent collection types (eg. Bags). These are very helpful for doing clever database operations, but don't serialize well at all! There is a quick fix for this: use DTOs (Data Transfer Objects). These can be small and simple objects, relying on the notion that your connecting client need know nothing about the server-size implementations. There's a bit of effort involved in transferring data from your underlying types into these DTOs, but in terms of simplicity, they save the day.

When using an ORM such as NHibernate, it's possible you'll run into these. NHibernate likes to subclass your data classes and replace lists and things with its own persistent collection types (eg. Bags). These are very helpful for doing clever database operations, but don't serialize well at all! There is a quick fix for this: use DTOs (Data Transfer Objects). These can be small and simple objects, relying on the notion that your connecting client need know nothing about the server-size implementations. There's a bit of effort involved in transferring data from your underlying types into these DTOs, but in terms of simplicity, they save the day. NB. There are other solutions out there - one of which is to force NHibernate to unproxy your objects before transmitting them. Trent Foley writes about that here.

You need to create a new basicHttpBinding , and give it high values for maxBufferSize and maxReceivedMessageSize . (In the example to the right, I'm using 2097152 - which is 2Gb.) Inside <system.serviceModel>, create a new <bindings> section, inside that a <basicHttpBinding> section, and inside that a new binding: <binding name="twoGigBinding" maxBufferSize="2097152" maxReceivedMessageSize="2097152" />

, and give it high values for and . (In the example to the right, I'm using 2097152 - which is 2Gb.) Inside <system.serviceModel>, create a new <bindings> section, inside that a <basicHttpBinding> section, and inside that a new binding: You need to create a protocolMapping section. You can use this to map the new binding by default to all http endpoints. It's easier to do this than to create a <services> section and create all the endpoint configurations, as they're only generated automatically for you (by the default configuration) if you do not attempt to define any. Inside the <protocolMapping> section, create the mapping between http and twoGigBinding: <add scheme="http" binding="basicHttpBinding" bindingConfiguration="twoGigBinding" />

section. You can use this to map the new binding by default to all http endpoints. It's easier to do this than to create a <services> section and create all the endpoint configurations, as they're only generated automatically for you (by the default configuration) if you do not attempt to define any. Inside the <protocolMapping> section, create the mapping between http and twoGigBinding: That's almost it. It's also a good idea to increase the object count available to the DataContractSerializer. To do that, add a new <dataContractSerializer> tag to the behaviour defined inside: <system.ServiceModel><behaviors><serviceBehaviors><behavior>: <dataContractSerializer maxItemsInObjectGraph="2147483646"/>

Right click the Config File for your service in WCF Test Client, and choose 'Edit with SvcConfigEditor'. Now you have a series of small changes to make.

Inside the Bindings folder, open up the binding you're working with, and adjust MaxBufferSize and MaxReceivedMessageSize to the new, higher value you set on the server (2097152).

Inside the Advanced / Endpoint Behaviours folder, create a new behaviour and call it something like LargeEndpointBehaviour.

Add a dataContractSerializer element to the LargeEndpointBehaviour, and set its maxItemsInObjectGraph property to the new, higher value you set on the server (2147483646).

Now go to the Client / Endpoints folder, and open up the client endpoint configuration there. Set the Behaviour Configuration property to the name of your new behaviour (LargeEndpointBehaviour).

Save the new configuration file, and allow the WCF Test Client to reload it.

The first time you debug a web service after creating it, Visual Studio will launch the WCF Test Client - a very useful piece of kit - and preload it with the details of your service.In this article, we'll look first at testing your WCF service, and then an all-too-familiar issue that might crop up and spoil your fun!The WCF Test Client looks a bit like SoapUI , and is pretty similar in purpose: It allows you to connect to a service, enter some parameters and submit them to any given service method to see what you get.After the first time you run the WCF Client, Visual Studio will forget all about launching it again until you make significant changes to it - which means when you subsequently hit f5 or choose Debug, it won't run again. It's worth knowing how to bring it up...You can find it again by launching the Visual Studio Command Prompt, and launching wcftestclient.exe from there.Once connected, making use of it is as simple as filling in the fields you want to use on the methods available over the interface, and clicking Invoke.Inevitably there are going to be gotchas when making use of the WCF! You may well see a rather unhelpful warning from the WCF Test Client sayingThere are a couple of likely culprits:You're going to have to make some changes to the configuration files both server side and client side. I've assumed you've got a C# WCF web service in VS 2010 or later, and you're using the WCF Test Client to test.First, make sure that the client configuration is not being continually regenerated by the WCF Test Client every time it connects. The Options window is available in the Tools menu. Make sure that the 'Always regenerate config when launching services' checkbox is not selected.Next, open up the web.config for your WCF service, and take a look inside. Not much in there! That's because WCF now uses a 'default configuration' approach - keeping all the clutter to a minimum! Here's what you need to know:Good - that's the server side configuration taken care of. Now to edit the client side configuration. Good news! The WCF Test Client provides an editor called the SvcConfigEditor.With any luck, the new settings will take effect and you will be able send and receive much larger messages over WCF.So we've looked at testing WCF services using the WCF Test Client that comes with Visual Studio, and we've taken a look at a couple of problems that might arise when using WCF services - and how to work around them. Hopefully this will help to set you on course for a successful experience developing your own web services.