Debugging a WCF service is typically a straightforward process. First, the WCF service method in question is called either by a client application or the provided WCF test client in Visual Studio. Then, once the exception is encountered, the exception details and inner exceptions can be examined to determine the cause of the failure. However, this process is not as straightforward if the following exception is returned by the service:
The underlying connection was closed: The connection was closed unexpectedly.
This exception is thrown after the execution of the service method is completed, but before the response is sent to the client. Because of this, no exception details can be evaluated while debugging the service in Visual Studio. This exception is typically thrown by a failure of the WCF service to serialize the response correctly.
For example, look at the following source code:
[KnownType(typeof(Monkey))]
[KnownType(typeof(Zebra))]
[DataContract]
public abstract class Animal
{
[DataMember]
public DateTime FeedingTime { get; set; }
[DataMember]
public string Name { get; set; }
}
[DataContract]
public class Alligator : Animal
{
}
[DataContract]
public class Monkey : Animal
{
[DataContract]
public class Zebra : Animal
{
}
Notice how there is a KnownType for the Monkey and Zebra, but not for the Alligator. This is important because the service method being called returns a List<Animal>, which contains an Alligator, Monkey, and Zebra. Without the KnownType attribute, any alligator included in the collection will fail to be serialized because the DataContractSerializer has no knowledge of how to serialize an Alligator.
Executing this service method will cause the “underlying connection” exception to be thrown. In order to view the details for what is actually happening, WCF tracing must be enabled in the service. This is done by simply copying the following XML into the web.config of the WCF service:
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="Verbose, ActivityTracing"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "C:\Programs\WcfService\Service.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
Upon further inspection of the configuration entry, the tracing is configured to return the trace information at the “Verbose” level and all logging will persisted to an xml file at the specified location.
After the logging has been added to the configuration file, call the service method in question. Once the method has finished executing, open the xml trace file in the svcTraceViewer.exe, which is included when installing the .NET SDK (typically at the following path: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin).
Drilling down into the trace file, you can find the exact point of failure for the WCF service:
Now, instead of the “underlying connection” exception message, you can see the actual exception details:
There was an error while trying to serialize parameter http://tempuri.org/:GetZooKeepersResult. The InnerException message was 'Type 'ZooModel.Alligator' with data contract name 'Alligator:http://schemas.datacontract.org/2004/07/ZooModel' is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.'. Please see InnerException for more details.
In this example, the KnownType attribute for the Alligator class was missing on an abstract class which cause the WCF serialization to fail.
Imagine having a WCF service method which returns an object composed of hundreds of classes. When you call this method, you get the “underlying connection” exception. Instead of spending hours inspecting each class to look for a serialization problem, you can enable tracing and solve the problem in minutes.