Yesterday we ran into some strange issues at customer site after deploying the server-side services of our application. These services are exposed through .NET Remoting to our own client-side application and to other applications. As these kind of deployments are rather routine than something exceptional, we wondered why the response to a remote call threw the following exception:
"Server encountered an internal error. For more information, turn on customErrors in the server’s .config file"
The first thing we checked was if our .NET Remoting services sent the same responses on requests of the applications installed on the same (physical) server as on requests coming in from other (physical) servers. As this wasn't the case - requests/responses on the same box were fine - the exception message thrown lead us immediately to the solution of the problem: the customErrors tag in the web.config of our .NET Remoting interface.
I won't elaborate further on the solution - switching the mode of the customErrors tag from "remoteOnly" to "Off" - because Chris Taylor already did a great job explaining the cause of this behavior in his post on Remoting Exceptions.
More information on the use of the customErrors element in the <system.runtime.remoting> configuration tag can be found here:
The mode-attribute indicates whether the server channels in this application domain return filtered or complete exception information to local or remote callers. The default is remoteOnly, which returns complete exception information (including the stack trace) only to callers on the same computer as the server.
Although I've nothing to add to Chris' post, I consider this behavior as unexpected ... Why?
Well doesn't .NET Remoting provides an abstract approach to interprocess communication that separates the remotable object from a specific client or server application domain and from a specific mechanism of communication? Doesn't this mean that your application should show a similar behavior whatever communication-protocol you use? Isn't the communication mechanism just a kind of switch that should be configured to let client and remotable objects communicate? Until today I was convinced that switching the mode of the customErrors tag in the machine.config or web.config couldn't break an application ... Well, guess I was wrong! This also means that when scaling an application from a single to multiple servers could cause your application to break!
To conclude I think this issue shows why Indigo, the new and forthcoming programming model and communications infrastructure, should be considered as a good thing!
Oh, and btw all deployed applications are running smoothly after switching this setting! Hopefully Pieter's well-profiled and tuned application - to be deployed tonight - will run fine too!
[Updated] In this post Jelle Druyts goes a little bit further in commenting on the issue listed above. Worth reading ... and commenting!
[Via Kent Sharkey] The ASP.NET Developer Center published a brand new article on Custom Entity Classes: On the Way to Mastering ASP.NET: Introducing Custom Entity Classes.
When designing and building enterprise applications - and with performance in mind - I prefer custom entity objects. However, the discussion and the used arguments as stated in Kent's comment are not really new to me neither! I'm convinced that both typed and untyped DataSets could be pretty useful in some scenarios.