For a difference, a post that has nothing to do with SharePoint, but rather with WCF. In my team today, we had a really strange behavior of one of our web services. Everything was ok, except in one method, which was always on the client side throwing the following exception:<\/p>\n

<\/p>\n

\n

\u201cAn error occurred while receiving the HTTP response to http:\/\/ServiceHost\/ServiceName.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.\u201d<\/p>\n<\/blockquote>\n

Looking at the inner exceptions, two more levels could be noticed:<\/p>\n

\n

The underlying connection was closed: An unexpected error occurred on a receive.<\/p>\n<\/blockquote>\n

and<\/p>\n

\n

An existing connection was forcibly closed by the remote host<\/p>\n<\/blockquote>\n

Googling it didn\u2019t happen too much \u2013 some answers were going into direction that complex objects can not be serialized (which is not true, by the way), and other answers were going into direction that the serialized message length was too large, and that the maxRequestLength should be increased in web.config, something like:<\/p>\n

\n

<httpRuntime maxRequestLength=\u201dXyz\u201d\u2026. \/><\/p>\n<\/blockquote>\n

But hey, we were in the test phase, and our serialized messages were really small, this could not be it\u2026<\/p>\n

\u2026or wait, could it be?<\/p>\n

I looked again on our objects that we are serializing, and saw something like<\/p>\n

\npublic class MyClass\n{\n    public int Id { get; set; }\n\t\n    public string Name { get; set; }\n\t\n    public MyClass Parent { get; set; }\n\t\n    public List<MyClass> Children { get; set; }\t\n}\n<\/pre>\n
OK, that\u2019s it. In an instance of the object, we hold the instance of the parent object, and list of instances of the children objects. And while that\u2019s ok in .NET class, because we are dealing with the \u201cpointers\u201d to the parent and child objects, it looks much different when we serialize it. It serializes the object, then it\u2019s parent object, then the children of the parent object (our starting object is among them), then again the parent\u2026 And it serializes infinitely. Until we hit the maximal message size, whatever it would be.<\/p>\n
Now, once the problem was diagnosed, the solution was also more than simple \u2013 we just put the DataContract attribute on the object, and exclude the “Parent” object property from the contract. Instead, we created a ParentObjectId property, getter only, which only returns the parent\u2019s id. <\/p>\n
\n[DataContract]\npublic class MyClass\n{\n    [DataMember]\n    public int Id { get; set; }\n    \n    [DataMember]\n    public string Name { get; set; }\n    \n    \/\/Notice - no [DataMember] here...\n    public MyClass Parent { get; set; }\n    \n    [DataMember]\n    public int ParentId \n    {\n        get\n        {\n            return this.Parent.id;\n        }\n    }\n    \n    [DataMember]\n    public List<MyClass> Children { get; set; }\n}\n<\/pre>\n
And voila \u2013 in the .NET libraries, we can still use the beauty of parent and children collection objects, and when we serialize it, we use the parent ids. Works like a champ. Simple problem, simple solution, but it has caused some thinking on our side.<\/p>\n
PS. Btw, don’t you love the WCF Exceptions? They are the only one that compare to SharePoint exception in providing senseful information.<\/p>\n
\n\t\t\t  
\n\t\t\t  <\/div><\/div>\n\t\t