if (Me.ForgotWhatChangedInDotNet20)
I got reminded by a fellow developer of some changes made to the machine.config in the .NET 2.0 Framework today.
The scenario: a request was being made from a windows client to a component being hosted through IIS. This particular request was already known to be a long running synchronous operation. ASP.NET was reaching its execution timeout and sending said notification back to the windows client.
This is not something new to the development team. They have conquered this nefarious beast before when the .NET Framework version that supported the hosted component was 1.1. They had made the switch many months ago. This particular component has been successfully consuming network bandwidth for extraordinary long periods to complete requests since then without an issue.
Along comes me, full of ideals and an outsider to their team. I noticed that the compilation debug attribute is set to true in their component’s configuration file. No one remembers how it got that way, but everyone outwardly agrees that it should not be that way. I suggest we change the attribute to false.
Such a suggestion gets implemented. I have been known to come up with good ideas every now and then. Solve problems… you know…all that jazz. Anywho, change gets promoted and … that’s how we get back to ASP.NET was reaching its execution timeout.
As I said, they had previously conquered this problem in the past with .NET 1.1. They set the httpRuntime executionTimeout in their machine.config file. Turns out, that in .NET 2.0, [… The httpRuntime element is not explicitly defined in the Machine.config file or in the root Web.config file. (from MSDN http://msdn2.microsoft.com/en-us/library/e1f13641.aspx ) …]
Why was this not a problem before you ask? Here is another tidbit from the same article [… This time-out applies only if the debug attribute in the compilation element is False …] So, since the debug attribute had been previously set to true the default value for the executionTimeout had been ignored.