Using a binary formatter with an HTTP channel during development has the undesirable side effect of masking server-side errors. For example, a general server error or an access violation will both be misreported to the client. This is due to the fact that when using a binary formatter the client-side Remoting component expects a message to be returned in binary format. Plain-text error results are not interpreted correctly and are reported as follows:We were pretty sure that some time-out setting was causing this exception because the timing was each time around 90 seconds after the start of the remote call, but we didn't know where we had to look for it. We thought that the time-out on the server (in IIS) was the only setting we could control for remote calls, but apparently there's also a default setting in the machine.config for an executionTimeout on the httpRuntime element. This executionTimeout specifies the maximum number of seconds that a request is allowed to execute before being automatically shut down by ASP.NET. This time-out applies only if the debug attribute in the compilation element is False. In .NET 2.0 the default is 110 seconds, while the default in .NET 1.0 and 1.1 is 90 seconds. A simple change in our web.config (executionTimeout="180") to override this setting and our problem was solved. The call could finish in time without an exception thrown at the client.
An unhandled exception of type 'System.Runtime.Serialization. SerializationException' occurred in mscorlib.dll. Additional information: BinaryFormatter Version incompatibility. Expected Version 1.0. Received Version 1008738336.1684104552.