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?
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)
Do you have the stack trace? I am curious as to what is throwing the exception. Is it from MobileFormatter, or WCF?
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
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>
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 DataContractSerializer in one important way: the includes CLR type information in the serialized XML, whereas the DataContractSerializer does not. Therefore, the can be used only if both the serializing and deserializing ends share the same CLR types. differs from the
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?
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).
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:
Exactly what i thought, but wanted to be sure.
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