Lost a few hours on this one today! Here’s what happened: At some point in our application I get hold of an object graph (an instance of a DataContract) which I need to serialize and store in the database. No big deal, I thought…
As any good citizen, I started with a test. First a unit test, then a minor integration test. Fine, time to put it in the app. After doing so, however, both Cassini and IIS died on me with an ExecutionEngineException as soon as WriteObject got called. WTF?!
Apparently, there’s this bug that’s been bugging me today:
When data contract contains property of type IEnumerable<T> where T is another data contract .NET crashes after handling the request (.NET crashes after operation method is invoked and returns the result).
If a OperationContract is defined to return IList<T> where T is a type defined by a DataContract, and an array is returned, then WCF throws an ExecutionEngineException.
Both entries are describing a somewhat different context, but I was sure it was the same problem. Since I was using a shared assembly, I didn’t have the freedom to ‘play around’ with the data contracts to see if I could do something about it. What I did notice, though, was that I was able to serialize other, far more complex, data contract without any problem. Also, the data contracts has concrete Lists defined, not interfaces. Weird.
Anyway, putting the shared assembly in the GAC, did indeed solve the problem. Five minutes later someone tells me (I’m new there) we’re not allowed to put assemblies in the GAC on our servers… ain’t that just sweet? I think I’m gonna give the IDataContractSurrogate a try tomorrow, one never knows.
