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?
Does anyone have any useful advice on this? I'd really like to know what other's have been doing to deal with this.
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
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.
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.
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