Debugging exception in WCF IsOneWay=True WCF Services

Recently I had to work on an one way WCF service. The scenario is little different than normal service hosting. There are many services hosted in a server machine using IIS WAS hosting.All of those expose same contact interface. The URLs are obviously different but they follow certain convention such as

net.pipe://localhost/{feature name}/service.svc

The caller has some logic to prepare the above url and it simply calls the service. It uses fire and forget method by decorating contract with IsOneway=True. Below is a similar contract.

---

[OperationContract(IsOneWay = true)]
void InvokeAsync(Dictionary<string, object> messageInfoDictionary);

---

After setting up the environment, we started facing one issue. The service implementation is not getting executed. But there is no exception in caller side. In a normal scenario we immediately go to the svclog file, if there is an exception. As there was no exception, the investigation didn't turn into svclogs in the first round.

Analyzed each and every bit of caller code where the url is prepared. No problem at all. Checked the contract methods again and again for any mismatch. Its all perfect. Finally decided to turn on the svclogs in caller side on the assumption that client is not able to establish communication with server.

It shows that there is timeout. But it didn't help to identify the root cause. Then enabled server side svclogs and it helped.

The exception was System.ServiceModel.Dispatcher.NetDispatcherFaultException .It has an inner exception as well which is of type System.Runtime.Serialization.SerializationException. The error message was

"Element 'http://schemas.microsoft.com/2003/10/Serialization/Arrays:Value' contains data from a type that maps to the name 
'http://schemas.datacontract.org/2004/07/{Namespace}:Message'. The deserializer has no knowledge of any type that maps to this name. Consider using a DataContractResolver or add the type corresponding to 'Message' to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding it to the list of known types passed to DataContractSerializer."

Yes its clear the data contract class is in different assembly and that assembly is not available in the bin folder of service. Putting the dll in place fixed the issue.

---

I am more researching on how these kind of issues can be caught in our code and log properly. This is important as the services which are exposing the same contract are going to be developed by different  and disconnected teams.