Plunging into .NET Development

Weblog Pieter Gheysens
Microsoft .NET Development - C# - Enterprise Library - Visual Studio 2005 Team System - Compuware DevPartner - ...

Saturday, October 28

.NET Remoting - executionTimeout

Recently we've experienced time-out problems with remote calls (.NET Remoting - http channel / binary formatter). On our remoting website in IIS we've set a time-out of 180 seconds, while after approximately 90 seconds we received the usual System.Runtime.Serialization.SerializationException for server-calls which take more than 90 seconds to execute.
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:

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.
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.

Links :


  • At 5:39 PM, Anonymous Anonymous said…

    Where in your web.config did you add the executionTimeout="180" setting? Did you have to create a new "httpRuntime" section for this? Sorry for asking what may seem like such a simple question, but I'm not a developer.


  • At 9:16 PM, Blogger Pieter said…

    Yes, you need to create the httpRuntime section in your web.config.


Post a Comment

Links to this post:

Create a Link

<< Home