First, create the application setup described in my WCF - Establishing a sample app baseline blog entry.

We will then modify the client program so that it encounters some errors while communicating with the WCF Service.

Next, add a new method to ConsoleApp1:

        private static string GenerateStringOfCertainLength(int stringLength)
        {
            string returnValue = String.Empty;
            int numTens = stringLength / 10;
            int remainder = stringLength % 10;

            for (int counter = 0; counter < numTens; counter++)
            {
                returnValue += "0123456789";
            }
            for (int counter = 0; counter < remainder; counter++)
            {
                returnValue += counter.ToString();
            }

            return returnValue;
        }

Replace the contents of the try block in ConsoleApp1 with:

                ServiceReference1.Service1Client oneService1Client = new ServiceReference1.Service1Client();
                ServiceReference1.CompositeType oneCompositeType = new ServiceReference1.CompositeType();
                oneCompositeType.StringValue = GenerateStringOfCertainLength(8193);
                oneCompositeType = oneService1Client.GetDataUsingDataContract(oneCompositeType);

Ctrl-F5 (Debug -> Start Without Debugging)

This may crash Cassini (the VS Web Server) and will result in the following exception:

--
oneException=[System.ServiceModel.FaultException: The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:composite. The InnerException message was 'There was an error deserializing the object of type WcfApp1.CompositeType. 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 1, position 8652.'.  Please see InnerException for more details.

Server stack trace:
   at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at ConsoleApp1.ServiceReference1.IService1.GetDataUsingDataContract(CompositeType composite)
   at ConsoleApp1.ServiceReference1.Service1Client.GetDataUsingDataContract(CompositeType composite) in C:\dev\Prototyping\WCF\WcfApp1\ConsoleApp1\Service References\ServiceReference1\Reference.cs:line 120
   at ConsoleApp1.Program.Main(String[] args) in C:\dev\Prototyping\WCF\WcfApp1\ConsoleApp1\Program.cs:line 17]
--

If we send 50000 instead of 8193, we get a different exception:

--
oneException=[System.ServiceModel.ProtocolException: The remote server returned an unexpected response: (400) Bad Request. ---> System.Net.WebException: The remote server returned an error: (400) Bad Request.
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---

Server stack trace:
   at System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest request, HttpWebResponse response, HttpChannelFactory factory, WebException responseException)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ClientReliableChannelBinder`1.RequestClientReliableChannelBinder`1.OnRequest(TRequestChannel channel, Message message, TimeSpan timeout, MaskingMode maskingMode)
   at System.ServiceModel.Channels.ClientReliableChannelBinder`1.Request(Message message, TimeSpan timeout, MaskingMode maskingMode)
   at System.ServiceModel.Channels.ClientReliableChannelBinder`1.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityRequestSessionChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at ConsoleApp1.ServiceReference1.IService1.GetDataUsingDataContract(CompositeType composite)
   at ConsoleApp1.ServiceReference1.Service1Client.GetDataUsingDataContract(CompositeType composite) in C:\dev\Prototyping\WCF\WcfApp1\ConsoleApp1\Service References\ServiceReference1\Reference.cs:line 120
   at ConsoleApp1.Program.Main(String[] args) in C:\dev\Prototyping\WCF\WcfApp1\ConsoleApp1\Program.cs:line 17]
--

The out of the box wizard generated service has a couple of limitations in string lengths that it will support.

These are essentially client side errors and can't be usefully debugged on the server side or using tools like Fiddler.

Let's go back to the 8193 character string and solve that issue first.  We can do this by modifying the web.config for the WCF web service and the app.config for the console client application.

There is a tool in Visual Studio that gives us a property editor for WCF configuration.  You may or may not find it preferable to use the tool over modifying the xml files directly, but that is how I am going to describe the changes we need to make.

If you right click on the web.config in the Solution Explorer and don't see a menu option called "Edit WCF Configuration", do the following to get it added:

  In Visual Studio 2008, go to the tools menu, then select "WCF Service Configuration Editor"
    File -> Exit

Now, right click web.config in Solution Explorer -> Edit WCF Configuration

  Select Bindings -> New Binding Configuration...
    Please select a binding type: wsHttpBinding
  Select Bindings -> NewBinding0 (wsHttpBinding)
    Set Configuration -> Name to: CustomWsHttpBindingConfiguration
    Set ReaderQuotas Properties -> MaxStringContentLength to: 9000

  Select Services -> WcfApp1.Service1 -> Endpoints -> (Empty Name) [the first one - not mexHttpBinding]
    Select Endpoint Properties -> Binding Configuration: CustomWsHttpBindingConfiguration

  File -> Save
  File -> Exit

Any time we update the web.config file, we should update the service reference, even though in this case it is likely unnecessary:

  Solution Explorer
    Right Click ConsoleApp1 -> Service References -> ServiceReference1
      Update Service Reference
      OK

We need to make the same change on the client side as we made on the server side:

  Right Click app.config in Solution Explorer -> Edit WCF Configuration
    Select Bindings -> WSHttpBinding_IService1 (wsHttpBinding)
      Set ReaderQuotas Properties -> MaxStringContentLength to: 9000
    Save & Exit

If we run the application now using 8193, the exception is gone.  So, it is now clear how to send strings larger than 8192 characters to a WCF web service (the exception helped point us in the right direction).

Now, let's go back to the 50000 scenario.  The above changes are not enough to fix it as we are now exceeding a different character limit.

Right click web.config in Solution Explorer -> Edit WCF Configuration
  Select Bindings -> CustomWsHttpBindingConfiguration (wsHttpBinding)
    Set General -> MaxReceivedMessageSize to: 75000
    Set ReaderQuotas Properties -> MaxStringContentLength to: 50000
  Save & Exit

Right Click app.config in Solution Explorer -> Edit WCF Configuration
  Select Bindings -> WSHttpBinding_IService1 (wsHttpBinding)
    Set General -> MaxReceivedMessageSize to: 75000
    Set ReaderQuotas Properties -> MaxStringContentLength to: 50000
  Save & Exit

Again, just for best practice reasons, we update the service reference:

  Solution Explorer
    Right Click ConsoleApp1 -> Service References -> ServiceReference1
      Update Service Reference
      OK

How did I come up with those numbers?  Trial and error.  The value for MaxStringContentLength logically matches the length of the string we are trying to send.  MaxReceivedMessageSize seems to include extra characters, but it's not clear to me what exactly those extra characters are.

If you increase the values of these two config settings on the server, but not the client, the client starts giving useful error messages (like: The maximum message size quota for incoming messages (70000) has been exceeded.) instead of the mostly useless "(400) Bad Request." which basically means that the server rejected your request and is pretty much unwilling to tell you why.

Please note that increasing the size of these config settings makes your web service more vulnerable to denial of service attacks.

It's pretty easy to exceed the wizard generated values however if you are, for example, trying to send the contents of a text file as a string parameter to a WCF method.

So, now you know how to configure WCF to allow sending larger strings back and forth.

First, create the application setup described in my WCF - Establishing a sample app baseline blog entry.
We will then modify that simple application so that it's traffic will show up in Fiddler2.

Second, install and startup Fiddler.  It is probably worth watching the QuickStart video if you haven't already.
After you install and run Fiddler, and then run ConsoleApp1, you'll notice that the WCF traffic doesn't show up in Fiddler.  There are multiple ways to enable that, but we are only going to cover one simple one right now.

Third, modify the client application so that Fiddler will display it's traffic.

After this line of code in ConsoleApp1 Program.cs Main:

ServiceReference1.Service1Client oneService1Client = new ServiceReference1.Service1Client();

Add:
                oneService1Client.Endpoint.Address = new System.ServiceModel.EndpointAddress(
                    new Uri(oneService1Client.Endpoint.Address.Uri.ToString().Replace("localhost", "127.0.0.1.")),
                    oneService1Client.Endpoint.Address.Identity,
                    oneService1Client.Endpoint.Address.Headers);

This essentially pushes all the network traffic into a place where Fiddler can see it (the period after the 1 is critical, it's not a typo!).

Ctrl-F5 (Debug -> Start Without Debugging)

You should now see traffic showing up in Fiddler.

If you shut down Fiddler, the application will still work fine (but if you used "ipv4.fiddler" instead of "127.0.0.1.", you would get an exception like: [EndpointNotFoundException: There was no endpoint listening at http://ipv4.fiddler:1100/Service1.svc that could accept the message.]).

At this point, for readability/testability purposes, I would encourage you to modify the web.config for the WCF service and replace the wsHttpBinding with the basicHttpBinding.  This will make it much more clear what is going on.

If you modify the WCF web.config, you have to update the reference in the client (which will generally regenerate the client's app.config to match):

Solution Explorer
 Right Click ConsoleApp1 -> Service References -> ServiceReference1 -> Update Service Reference

(This is basically needed anytime the WCF application changes it's public interface.)

We are going to run the WCF application wizard and then create a client program that establishes basic communication with that WCF Service.

We will be using Visual Studio 2008 with Service Pack 1

File -> New -> Project
 Visual C# -> Web -> WCF Service Application
  WcfApp1 -> OK
Solution Explorer
 Right Click Solution -> Add -> New Project
  Visual C# -> Windows -> Console Application
   ConsoleApp1 -> OK

Solution Explorer
 Right Click ConsoleApp1 -> References -> Add Service Reference...
  Discover
  OK

If adding the service reference fails, try to run WcfApp1 (Debug -> Start Without Debugging) and click on "Service1.svc" first.  For whatever reason, the WCF service doesn't always "auto-start" when it should.  I end up using this "workaround" quite often.

Add the following to the Main method in Program.cs in ConsoleApp1:

            try
            {
                ServiceReference1.Service1Client oneService1Client = new ServiceReference1.Service1Client();
                string serviceOutput = oneService1Client.GetData(-1);
                Console.WriteLine("serviceOutput=[" + serviceOutput + "]");
            }
            catch (Exception oneException)
            {
                Console.WriteLine("oneException=[" + oneException.ToString() + "]");
                Environment.Exit(-1);
            }

Solution Explorer
 Right Click ConsoleApp1 -> Set as StartUp Project

Ctrl-F5 (Debug -> Start Without Debugging)

Program output should be:

--
serviceOutput=[You entered: -1]
Press any key to continue . . .
--

We now have a basic WCF application with a basic client that calls it.

One very helpful tip once the basics are running is to get Fiddler up and running to be able to watch WCF traffic in case things go downhill after you make some changes.

Click here for instructions on how to do that.

One of my personal pet programming projects at one point in time was to create some kind of screen scraper of monster.com and other job websites so I could "download" all the current job postings and do things like:

1) Rank/Prioritize the job listings by personal appeal
2) Detect job listing duplicates between monster/dice/etc.
3) Keep track of which jobs I applied for and when
4) Automate running multiple queries with multiple terms in job site specific ways so I could detect new entries in my areas of interest (something an RSS feed would normally be used for)
5) Categorize jobs by factors that were important to me - Salary, Location, Consulting vs. Full-time, How qualified I thought I was, etc.

Everyone puts that much effort into their job search, right?  ;)

I did get something of an automated process for the worst bits with tons of manual intervention required such that I could do this and it worked wonderfully.  It was never anywhere close to automated enough to share with friends though.  However, screen scrapping different web sites is not fun, rewarding work and I eventually shelved the project (and I now find most of my contract work through recruiters who I've talked to in the past and never apply for jobs from web site job listings anymore).

I still think this is very cool though:

http://www.indeed.com/jsp/apiinfo.jsp

Indeed is yet another job search engine, except with one major difference (it may not be the only job search engine with this feature, but it's the only one I know of).  Indeed publishes a Web Services API which you can query directly that seems to return job listings from Monster, Dice, etc.  This would have made my pet project above a piece of cake to implement.  This is a very good sign of things to come in the web services world!

Now if someone would just publish a web service for stock price quotes (you know it's going to happen eventually).