Gotcha. So in your case ASP.NET is the client which calls the remote
components, right? You should still be able to see the exception being
caught in your ASP.NET app by setting the customErrors attribute in the
Web.config to "Off". Otherwise try triggering the exception by running a
browser on the same machine as the ASP.NET application.
[quoted text, click to view] "Ray Stevens" <nfr@nospam.com> wrote in message
news:%23lzxXMoqFHA.2592@TK2MSFTNGP09.phx.gbl...
> The remoting application is not running in asp.net. It is a bll/dal
> application layer running as a service and is of the form:
> FloodRemoteHostService.exe.config. Is customErrors supported here?
>
> "Beth Massi [Architect MVP]" <bmassi@comcast.net> wrote in message
> news:%23oZRAHoqFHA.2244@tk2msftngp13.phx.gbl...
>> In your Web.config, make sure you also set the typeFilterLevel attribute
>> to "Full" if you're passing any custom exceptions:
>>
>> <channels>
>> <channel ref="http">
>> <serverProviders>
>> <formatter ref="binary" typeFilterLevel="Full" />
>> </serverProviders>
>> </channel>
>> </channels>
>>
>> Also, the settings are case sensitive so make sure you specified the
>> customErrors mode like:
>>
>> <customErrors mode="Off" />
>>
>> note the capitalized "O"
>>
>> HTH,
>> -B
>>
>> "Ray Stevens" <nfr@nospam.com> wrote in message
>> news:Ohn97mmqFHA.2596@TK2MSFTNGP09.phx.gbl...
>>> That is not a particularly useful error message. this is being thrown by
>>> a remoting server accessing the bll/dal layers from a web. I turned off
>>> customErrors in the remote config file, but still get this error.
>>>
>>> Anyone have a clue as to what to do about it?
>>>
>>
>>
>
>