.NET 4.5.1 WCF Serialization exception

.NET 4.5.1 WCF Serialization exception

Old forum URL: forums.lhotka.net/forums/t/12195.aspx

rfcdejong posted on Thursday, October 24, 2013

Starting the client of our application on Windows 8.1 which talks to 2008 server (on 4.5). With the WcfDataPortal

The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://ws.lhotka.net/WcfDataPortal:FetchResult. The InnerException message was 'Error in line 1 position 11619. 'Element' 'm_serializationArray' from namespace 'http://schemas.microsoft.com/2003/10/Serialization/Arrays' is not expected. Expecting element 'm_keyRehashCount'.'.  Please see InnerException for more details.

The most inner exception is

Error in line 1 position 11619. 'Element' 'm_serializationArray' from namespace 'http://schemas.microsoft.com/2003/10/Serialization/Arrays' is not expected. Expecting element 'm_keyRehashCount'.

Is this a know issue, must the server be upgraded to 4.5.1 somehow or must the client be forced to run on 4.5 only?

rfcdejong replied on Saturday, October 26, 2013

Is there someone with a working project configured in the same configuration?

- Server side without .NET 4.5.1. (only 4.5 installed)
- Client side with .NET 4.5.1 


Praburaj from the .NET compatibility team is willing to investigate if .NET is the issuer (and not CLSA or our software)

RockfordLhotka replied on Saturday, October 26, 2013

Do you have the stack trace? I am curious as to what is throwing the exception. Is it from MobileFormatter, or WCF?

rfcdejong replied on Monday, October 28, 2013

It seems to be a compatibility issue between .NET 4.5 and .NET 4.5.1. when using a ConcurrentDictionary<string, int>

See the modified SimpleNTier attachment.

Running both client and server local it works
Running the client on 4.5 and the server on 4.5 it works
Running the client on 4.5.1 and the server on 4.5 it throws the exception

rfcdejong replied on Wednesday, October 30, 2013


Is it possible to use the DataContractSerializer in CSLA instead of NetDataContractSerializer ?
Or will we loose information while serializing?


See the quick response i got from the .NetFx 4.5 Compatibility team

From: <hidden by rfcdejong>
Sent: Tuesday, October 29, 2013 12:24 PM
To: 'Raymond de Jong'; NetFx 4.5 Compat
Subject: RE: .NET 4.5.1 compatibility issue when using a ConcurrentDictionary<int, string>


Hi Raymond,


Thanks for reporting this issue. I can reproduce this issue from my end. I am forwarding this issue for investigation. I would like to give a few facts to see if this would help you in the meantime.


NetDataContractSerializer (http://msdn.microsoft.com/en-us/library/system.runtime.serialization.netdatacontractserializer.aspx) is more restrictive than a DataContractSerializer as per the documentation.



The NetDataContractSerializer differs from the DataContractSerializer in one important way: the NetDataContractSerializer includes CLR type information in the serialized XML, whereas the DataContractSerializer does not. Therefore, the NetDataContractSerializer can be used only if both the serializing and deserializing ends share the same CLR types.


I believe the type ConcurrentDictionary in 4.5.1 has added a property or member variable named m_keyRehashCount which is not found in the 4.5 version of the ConcurrentDictionary. While trying to de-serialize this object on a 4.5.1 machine – the serializer expects this missing property resulting in this exception.




Will you be able to use DataContractSerializer instead of NetDataContractSerializer which supports compatibility between different versions of CLR objects?





JonnyBee replied on Wednesday, October 30, 2013

I believe the answer is no.

You need a "binary" serializer and from the built-in ones in .NET there is the BinaryFormatter and NetDataContractSerializer (ie serializers that support the [Serializable] attribute - and DataContractSerializer does NOT).

Apply the DataContractAttribute attribute to classes, and the DataMemberAttribute attribute to class members to specify properties and fields that are serialized.

The types and properties (internally in CSLA and business classes/properties) are NOT marked with these attributes.

Another alternative may be to use the new CSLA mobile binary formatters and confire the CslaReaderWriterFactory to use one of the following sets:

rfcdejong replied on Wednesday, October 30, 2013

Exactly what i thought, but wanted to be sure.

RockfordLhotka replied on Friday, November 01, 2013

If Microsoft did change the internal structure of one of their types then that could easily break the BinaryFormatter and NetDataContractSerializer. That's pretty nasty, and isn't something that has occurred (to my knowledge) since the .NET 1.1 to 2.0 transition.

As Jonny suggests, the MobileFormatter is more "controllable" in this regard. But you'll probably need to create your data type for your collection similar to the MobileXYZ types in Csla.Core to serialize your particular type.

Copyright (c) Marimer LLC