Maybe this has been covered already but here’s something that messed me up this morning. I was trying to set up a wpf app with a remote portal and kept getting the cryptic “The underlying connection was closed: The connection was closed unexpectedly.”
Exception Stack trace showed the issue to be somewhere at:
at Csla.Server.Hosts.IWcfPortal.Fetch(FetchRequest request)
at Csla.DataPortalClient.WcfProxy.Fetch(Type objectType, Object criteria, DataPortalContext context)
Debugging through the code showed that, indeed, a valid exception was being thrown but the details were getting lost somewhere between the server and client...
From Client proxy.Fetch:
\csla\DataPortal.cs
try
{
result = proxy.Fetch(objectType, criteria, dpContext);
}
catch (Server.DataPortalException ex)
{
…..
}
catch (Exception ex)
{
**** true exception details lost at this stage ****
OnDataPortalInvokeComplete(new DataPortalEventArgs(dpContext, objectType, DataPortalOperations.Fetch, ex));
throw;
}
The exception gets raised from:
\csla\server\DataPortal.cs
if (ApplicationContext.AuthenticationType == "Windows")
{
// When using integrated security, Principal must be null
if (context.Principal != null)
{
System.Security.SecurityException ex =
new System.Security.SecurityException(Resources.NoPrincipalAllowedException);
//ex.Action = System.Security.Permissions.SecurityAction.Deny;
throw ex;
}
And the response does appear to include the exception details:
\csla\server\hosts\wcfportal.cs
[OperationBehavior(Impersonation = ImpersonationOption.Allowed)]
public WcfResponse Fetch(FetchRequest request)
{
Csla.Server.DataPortal portal = new Csla.Server.DataPortal();
object result;
try
{
result = portal.Fetch(request.ObjectType, request.Criteria, request.Context);
}
catch (Exception ex)
{
result = ex;
}
return new WcfResponse(result);
}
I'm wondering am i missing something in how a client can figure out what a server exception actually is? If this were production I'd be scratching my head ferociously.
Hi,
Look at Samples\Net\cs\CustomerErrorHandling on how to catch and transform non serializable exception or non existing exceptions on the client machine to a generic exception the client can handle.
Thanks Jonny. I'll certainly take a look at that.
As an aside is there any way on this forum to PM you?
Having thought about this for a second...I'm using WPF so surely the SecurityException is available on the client side?
But is SecurityException and all the inner exceptions both Serializable and existing on the client.
When using WebSphere MQ and Teradata (or other custom DataProviders) their exceptions will not exist on the client side.
Hi Jonny,
Well in this case there are no inner exceptions. The SecurityException is created right there in Rocky's code and thrown:
System.Security.SecurityException ex = new System.Security.SecurityException(Resources.NoPrincipalAllowedException);
throw ex;
So I suppose, as this is rich windows client, I would have expected to see this exception come back in some form rather than the generic "the underlying connection, etc...." exception.
I'll tag it for revisit when I get time and see if I cannot figure out where exactly it is getting lost.
As always, I appreciate you taking the time to reply.
What you're running into is one of the tenets of WCF - by default, exceptions thrown on the server do not flow to the client. There are configuration options you can set to let exceptions flow through, but in its default state this is what you get. And that's regardless of what type of client is connecting to the service.
HTH
- Scott
That certainly makes sense. Thanks for that.
You can PM me on jonny.bekkum(a)gmail.com
Copyright (c) Marimer LLC