WCF- "The underlying connection was closed: The connection was closed unexpectedly"

I'm recieving that wonderfuly ambiguous error message when using one of my webmethods on my WCF webservice. As that error message doesn't provide any explanation whatsoever allow me to post my theory.

I believe it may have something to do with the return type I'm using

I have a Types DLL which is refrenced in both the webservice and the client. In this DLL is the base class ExceptionMessages. There is a child of this class called DrawingExcepions.

Here is some code:

public class ExceptionMessages
{
    public object[] ReturnValue { get; set; }
}

public class DrawingExceptions : ExceptionMessages
{
    private List<DrawingException> des = new List<DrawingException>();
}

public class DrawingException
{
    public Exception ExceptionMsg { get; set; }
    public List<object> Errors { get; set; }
}

The using code:

    [OperationContract]
    ExceptionMessages createNewBom(Bom bom, DrawingFiles dfs);

    public ExceptionMessages createNewBOM(Bom bom, DrawingFiles dfs)
    {
            return insertAssembly(bom, dfs);
    }

    public DrawingExceptions insertAssembly(Bom bom, DrawingFiles dfs)
    {
        DrawingExceptions des = new DrawingExceptions();

        foreach (DrawingFile d in dfs.drawingFiles)
        {
            DrawingException temp = insertNewDrawing(bom, d);
            if (temp != null)
                des.addDrawingException(temp);

            if (d.Child != null)
                des.addDrawingException(insertAssembly(bom, d.Child));
        }

        return des;
    }

Returns to:

    ExceptionMessages ems = client.createNewBom(bom, currentDFS);

    if (ems is 开发者_高级运维DrawingExceptions) { }

Basically the return type from the webmethod is ExceptionMessages however I would usually be sending the child class back instead.

My only idea is that it's the child that's causing the error but as far as I've read, this should have no effect. Has anyone got any ideas what could be going wrong here?

If any more info is required, just ask :)

Thanks.

Yes, this message is great :)

I have often found it helpful to enable tracing, as described in this article. Have a look at the section called 'Recommended Settings for Deployment or Debugging'.

I was getting this error when returning a large payload, it turned out to be the DataContractSerialiser stopping mid stream as it had hit the default maxItemsInObjectGraph setting, adding the folloing to my endpoint behavour fixed the problem.

<dataContractSerializer maxItemsInObjectGraph="2147483647" />

I had the same issue and I came upon this post as a possible solution to a timeout error that my WCF service was having. In my case squig's answer offered a clue as to the underlying condition. While it's easy to up the size of the max payload, that is obviously an option with performance implications.

In my case, I'm uploading an object graph to be saved, then returning the updated object to my client so I can keep track of foreign keys, etc. For my problem the question was how could it have gotten so much bigger on the return trip. I dug around and it struck me that the root cause of the expanded payload size was that when I added a child object to my object graph, the navigation properties of those child objects added references to the parent, which had references to the child, and so on and so on.

I went to my edmx file, removed the navigation properties from the offending child objects and my package size was tamed.

Hope this helps someone else!

I have just had the same issue however none of the answers above solved the problem.

I was bringing back a List of LINQ objects, the database has all relationships set up correctly which causes objects to be linked automatically with LINQ... This was stopping the query from working.

I solved this by removing the relationships from the LINQ DBML