Jelle Druyts

Yesterday, David Boschmans blogged about a problem with .NET Remoting and customErrors we noticed at the customer's site earlier this week. It basically boils down to the fact that the customErrors tag in the <system.web> part of the web.config file is being read by the remoting infrastructure (if you're hosting in IIS anyway) to determine whether or not to flow remote exceptions to the caller. I find this very bizarre, as does David. Ingo Rammer left a little note in the comments about the way Indigo will handle this situation, and I'd simply like to add my opinion to the matter here.

I think some confusion lies in the fact that .NET Remoting was designed to be as transparent as possible. I think of it this way: exceptions are part of the contract of a class; .NET Remoting is "only" a means to provide location transparency, so the remoting stack should always ensure that the exception is transferred to the client. There shouldn't even be a setting that influences this, as far as I'm concerned. Especially if that setting lives in the <system.web> section, since I expect that section to only affect ASP.NET sites. Up until now, that wasn't a section I would typically associate with the remoting stack.

The same configuration setting does exist in the <system.runtime.remoting> section as well though, where I can somewhat accept its existance, but certainly not its default value ("remoteOnly") since that can effectively change the behaviour if you scale to multiple servers as David states. That means that if you host your client (e.g. a web app) and server (remoting backend) on the same physical machine, everything will appear to work correctly since the exceptions are transferred locally. If you decide to scale out and move your remoting layer to another server, you'll see an unexpected RemotingException where your own application exception used to be and your app won't work as it used to do (if you're using structured exception handling anyway).

Now, concerning Ingo's comment... Indigo is different. I would actually expect Indigo to have a means to specify the way server-side exception information is exposed, because Indigo was never meant to be transparent - quite the opposite actually: "Boundaries Are Explicit", remember. And with Indigo, you don't typically "trust" the client, whereas with remoting you tend to have a lot more control over the caller so you would allow more trust about the exceptions being transferred. Anyway, I'm looking forward to seeing the new Indigo model in action, and how the [FaultContract] will interact with the various .NET and non-Microsoft clients out there...