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();
oneService1Client.Endpoint.Address = new System.ServiceModel.EndpointAddress(
new Uri(oneService1Client.Endpoint.Address.Uri.ToString().Replace("localhost", "127.0.0.1.")),
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):
Right Click ConsoleApp1 -> Service References -> ServiceReference1 -> Update Service Reference
(This is basically needed anytime the WCF application changes it's public interface.)