Unexpected Type - Serialization Exception

I have a WCF service.

A normal operation will see that the server is doing some processing, returning a populated XactTaskIn object to the client using a callback. I am working fine.

My problem is that when I try to set the returnData variable to a populated XactException and try to send XactTaskIn back to the client using a callback, I get the following exception.

The exception is the "Type" XactException "with the data contract name 'XactException: HTTP://schemas.datacontract.org/2004/07/' is not expected. Consider using DataContractResolver or adding any types unknown statically in the list of known types - for example, using the KnownTypeAttribute attribute or adding them to the list of known types passed to the DataContractSerializer. " (System.Runtime.Serialization.SerializationException exception) Exception Message = "Type" XactException "with data contract name 'XactException: HTTP://schemas.datacontract.org/2004/07/' is not expected. Consider using DataContractResolver or add any types are unknown statically in the list of known types - for example, using the KnownTypeAttribute attribute or adding them to the list of known types passed to DataContractSerializer. ", Exception type =" System.Runtime.Serialization.SerializationException "

Here is the XactTaskIn class

[DataContract] public class XactTaskIn { [DataMember] public DateTime timeOut; [DataMember] public DateTime timeIn; [DataMember] public string name; [DataMember] public string responseTo; [DataMember] public String moduleFromName; [DataMember] public String moduleFromType; [DataMember] public String methodFromName; [DataMember] public object[] originalInputs; [DataMember] public String returnMethodToCall; [DataMember] public String returnModuleToCall; [DataMember] public object returnData; public XactTaskIn(DateTime timeOut, DateTime timeIn, string name, string responseTo, String moduleFromName, String moduleFromType, String methodFromName, object[] originalInputs, String returnMethodToCall, String returnModuleToCall, object returnData) { this.timeOut = timeOut; this.timeIn = timeIn; this.name = name; this.responseTo = responseTo; this.moduleFromName = moduleFromName; this.moduleFromType = moduleFromType; this.methodFromName = methodFromName; this.originalInputs = originalInputs; this.returnMethodToCall = returnMethodToCall; this.returnModuleToCall = returnModuleToCall; this.returnData = returnData; } } 

Here is the XactException class:

 [DataContract] public class XactException { [DataMember] string message; public XactException(string message) { this.message = message; // Add implementation. } } 

Update:

So, a comment from Daniel helped me.

Now it looks like the server sends a callback to the client, but the client throws the next exception.

  • Caught: "The formatter made an exception while trying to deserialize the message: an error occurred while trying to deserialize the parameter http://tempuri.org/:taskIn . The InnerException message was" Error at line 1 position 960. Element 'Http: //schemas.datacontract. org / 2004/07 /: returnData 'contains data from a type that displays the name' Http://schemas.datacontract.org/2004/07/:XactException. The deserializer does not know any type that maps to this name. Consider using a DataContractResolver or add a type corresponding to โ€œXactExceptionโ€ in the list of known types โ€” for example, using the KnownTypeAttribute attribute or adding it to the list of known types passed to the DataContractSerializer. '. See InnerException for more information. Details "(System.ServiceModel.Dispatcher.NetDispatcherFaultException) Exception Message =" The formatter threw an exception while trying to deserialize the message: an error occurred while trying to deserialize the parameter http://tempuri.org/:taskIn . The InnerException message was 'Error at line 1 position 960. The' Http://schemas.datacontract.org/2004/07/:returnData 'element contains data from a type that displays the name' Http://schemas.datacontract.org/2004 / 07 /: XactException. The deserializer does not know any type that maps to this name. Consider using a DataContractResolver or add a type corresponding to "XactException" in the list of known types - for example, using the KnownTypeAttribute attribute or adding it to the list of known types passed to the DataContractSerializer . '. See InnerException for more information. Details. ", Exception Type = "System.ServiceModel.Dispatcher.NetDispatcherFaultException"
+47
c # serialization exception-handling wcf
May 27 '11 at 13:44
source share
3 answers

In your class

  [DataContract] public class XactTaskIn 

you have properties returning objects:

  [DataMember] public object[] originalInputs; [DataMember] public object returnData; 

The WCF must know in advance what types can be there so that it can tell the client (via WSDL) that all types are. For any / all non-informative types (nothing that isnt int, string, DateTime, etc.) you will need to add the [KnownType] attribute for each possible type that can be passed back to these object properties, for example:

  [KnownType(typeof(XactException))] [KnownType(typeof(...))] [KnownType(typeof(...))] [DataContract] public class XactTaskIn 

Thus, when WCF creates a WSDL for this service, it will know how to add a XactException to the list of data types, and will also know that these serializers will look for these classes.




Side note; if your client was created using SrvUtil, Service Reference or somehow created from WSDL, you will need to rebuild the client after adding the [KnownType] attributes!

+79
May 27 '11 at 14:50
source share

Your client expects XactTaskIn to not throw a XactException.

You need to modify XactTaskIn to be able to pass the exception object back to your client.

Throw a datacontract exception and add an XactException type to the XactTaskIn class as a data member

0
May 27 '11 at 13:57
source share

Exceptions for Seriliazation occur when data changes, for example, something as trivial, as changing the field name from awesomeString to awesomeString will break serialization. The reason for this is that new data can no longer be checked against the background of old data. The fix for this is to use the old version expected by the server / client.

0
May 27 '11 at 14:37
source share



All Articles