.NET Remoting and CustomErrors

.NET Remoting and CustomErrors

Old forum URL: forums.lhotka.net/forums/t/5913.aspx


decius posted on Monday, December 01, 2008

Hi,

I'm working with Csla 3.0.5 and am struggling with a concept here.  It seems that if I throw an exception in my BO's DataPortal_XYZ, and try to catch it on the client, CustomErrors has to be set to "Off" or else I get:

System.Runtime.Remoting.RemotingException: Server encountered an internal error. For more information, turn off customErrors in the server's .config file.

It seems that the tag in the <system.web> part of the web.config file is being read by the remoting infrastructure to determine whether or not to flow remote exceptions to the caller. I find this very bizarre... why microsoft? why?

I can't use "RemoteOnly" because my client doesn't sit on the same physical box as the RemotingHost.

Is it typical to turn this off when using Csla's .NET Remoting?  Isn't that bad practice? 

 

 

decius replied on Tuesday, December 02, 2008

Does anyone have any useful advice on this?  I'd really like to know what other's have been doing to deal with this.

tmg4340 replied on Tuesday, December 02, 2008

Well... I don't think this is an issue specific to CSLA.  I will say that I'm pretty sure it's not the remoting infrastructure that's reading the tag - it's the ASP.NET IIS process that's reading the tag.  Given that, I suspect it has something to do with IIS parsing the request.  There's really no difference between a "normal" HTTP request and a remoting HTTP request...

Plus, there's probably a somewhat-reasonable argument that says since this is a service, setting "CustomErrors" to "Off" doesn't really hurt.  There's no UI to expose the ugly details to.  So what does it hurt to turn it off?  If someone happens upon your service from a browser, they are probably going to have a hard time actually getting the service to do anything.  And if they want to write a program to access it, then you have to fall back on whatever security you've coded into your service - which, if it's externally accessible, should be pretty robust.

Ultimately, to get what you want, I don't see any other solution than the one you've found.  But I'll admit my experience with remoting via IIS is limited.

HTH

- Scott

decius replied on Monday, December 08, 2008

Thank you for your response.  And yes, I didn't mean to phrase that in a way to blame Csla, it has to do with the core .NET components when using remoting.  Your response helped me confirm my thoughts about this.  Thanks!

ajj3085 replied on Monday, December 08, 2008

I have in my web.config custom errors set to off, and the exceptions do flow back to the client.  I didn't really muck around too much with configuration though.. I basically just took what the PTracker sample does and copied it line for line.

I'm not sure if that helps you or not though.

RockfordLhotka replied on Monday, December 08, 2008

The ASP.NET custom errors setting shouldn't impact the data portal (much).

There are three categories of problem you can encounter using remoting (or WCF, or asmx, etc) with the data portal.

  1. The connection from client to server can't be established or breaks
  2. The ASP.NET server is unable to load Csla.dll
  3. A problem occurs once the data portal is actually running on the server (note that 1 and 2 occur before the data portal starts running)

Issue 1 is purely a client-side exception handling thing.

Issue 2 may be affected by the ASP.NET custom errors setting, because this would be an ASP.NET failure. This should really only occur as you get your server set up - once it is running this should never happen.

Issue 3 is entirely handled by the data portal, and the ASP.NET custom errors setting should have absolutely no impact. When an exception occurs in the data portal, or in your server-side code, no "failure" is reported to ASP.NET. Instead, ASP.NET sees a successful result passed back to the client. That "successful result" actually contains a serialized exception, but ASP.NET and remoting are entirely unaware of that fact. Those technologies just see a binary blob, like they would for complete success.

AzStan replied on Thursday, December 02, 2010

Here's some information regarding getting remote server dataportal exceptions when using the data portal with the remoting chanel.

If I understand Rocky's message, the dataportal should gracefully trap remote server exceptions and deliver them to the client wrapped in a DataPortalException.

I was getting the desired result on my developement workstation, but the exceptions were not being passed from my remote production server.  When using the remote server, I would get a remoting exception, with the message: "Server encountered an internal error. For more information, turn off customErrors in the server's .config file."  The 'custom errors' setting didn't seem to matter... until I noticed that there is another 'custom errors' element available for configuring <system.runtime.remoting> (different from the one in <system.web>. see: http://msdn.microsoft.com/en-us/library/z415cf9a(v=VS.71).aspx (or search for remoting settings schema).

When I set the <system.runtime.remoting> ...<customErrors mode="on" /> </system.runtime.remoting> (psudo) element on my development machine, it acts like my production machine and won't pass any error information from the server data portal to the client.

When I set customErrors mode="off" on my production machine, it passes exception information just as advertised.

i'm a bit reluctant to set customErrors off on the production machine, even if it is just for the remoting channel, so this will probably spur me to configure WCF.  Hopefully this information will help somebody still using remoting.

 

Copyright (c) Marimer LLC