So far we have a contract, 2 client/server pairs (one programmatic and one administrative). We can observe that the highly difficult tasks of text concatenation and changing case are happening. But these examples are extremely trivial, and as we increase complexity, try new things, it would be nice to observer what is going on, especially when it does not go well.
Luck for us, there is a built in logging facility in .NET and a complete feature set and viewing tool specifically for WCF. And all can be accomplished via the config file. Let's hit the servers config file.
First, lets set up diagnostics...
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Information, ActivityTracing"
propagateActivity="true" >
<listeners>
<add name="xml"/>
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="xml"/>
</listeners>
</source>
<source name="myUserTraceSource"
switchValue="Information, ActivityTracing">
<listeners>
<add name="xml"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add name="xml"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="d:\logs\Traces.svclog" />
</sharedListeners>
</system.diagnostics>
This is straight out of the WCF help file. It defines 3 sources, that use a common trace log, located at d:\logs\traces.svclog. The first 2 come from system components, the third from a source I can drive. We are not currently driving it yet, but let's leave it in so we can put stuff in it later for debugging purposes.
So, the trace destination is there. Let's tell the WCF system to feed it.
The above big of config fell into the <configuration> section of our app.config. The next bit is inside our System.ServiceModel section.
<diagnostics wmiProviderEnabled="true">
<messageLogging
logEntireMessage="true"
logMalformedMessages="true"
logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="true"
maxMessagesToLog="3000"
/>
</diagnostics>
As you can see, we have enabled several things here. This produces a lot of good info about what is going on. We see the entire message, both good and bad, at both the service and transport level. You can trim this down. As we run the service, it puts our tracing in our log file. We could just open this file via Notepad, and brute force our way to knowledge, but guess what. There is a better way. svcTraceView.exe is part of the windows sdk. This gives us nice formatted output.
<MessageLogTraceRecord>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">MyService/IMyContractInterface/SayHelloResponse</Action>
</s:Header>
<s:Body>
<SayHelloResponse xmlns="MyService">
<SayHelloResult>hello bob</SayHelloResult>
</SayHelloResponse>
</s:Body>
</s:Envelope>
</MessageLogTraceRecord>
This is the message response from our "SayHello" method, which was given "bob" to append to the word "Hello ". Not bad.
We will come back to this took and logging periodically to view the effects of binding and hosting changes...
For now....