I have recently updated to CSLA 3.0, as well as changed a bunch of other code in my project (which just makes it even more fun in trying to isolate the problem), and I am now getting random unhanlded exceptions:
System.ServiceModel.Diagnostics.FatalException: Type is not resolved for member 'BOLayer.Security.CustomPrincipal, BOLayer, Version=2.0.0.0, Culture=neutral, PublicKeyToken=23f35140ddce47f3'. ---> System.Runtime.Serialization.SerializationException: Type is not resolved for member 'BOLayer.Security.CustomPrincipal,Biz.BOLayer, Version=2.0.0.0, Culture=neutral, PublicKeyToken=23f35140ddce47f3'. (The rest of the stack trace is below).
This seems closely related http://forums.lhotka.net/forums/post/12149.aspx, except I'm not running Cassini.
Here is my setup:
Windows Server 2003 SP1, running IIS and .net 3.0 for WCF
I have a WCF application setup for BasicHttpBinding. I am using a custom membership provider to handle authentiation for the WCF service. Inside the membership provider, I am making a call to CustomPrinciple.Login, which is CSLA based. I am not using WCF to make my data portal calls (yet).
As a work around, I tried installing my assemblies (membership provider, BOLayer and CSLA) into the GAC, and the error has gone away. While I wouldn't mind installing into the GAC, I guess I would prefer not to, so any help would be appreciated.
Thanks in advance
Here is the rest of the stack trace:
at System.Web.Hosting.ApplicationManager.RespondToPingIfNeeded()
at System.Web.Hosting.HostingEnvironment.RespondToPingButNotTooOften()
at System.Web.Hosting.HostingEnvironment.DecrementBusyCountInternal()
at System.Web.Hosting.HostingEnvironment.DecrementBusyCount()
at System.ServiceModel.ServiceHostingEnvironment.DecrementBusyCountNoInline()
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
--- End of inner exception stack trace ---
at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
at System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(RequestContext request, Boolean cleanThread, OperationContext currentOperationContext)
at System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(RequestContext request, OperationContext currentOperationContext)
at System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(IAsyncResult result)
at System.ServiceModel.Dispatcher.ChannelHandler.OnAsyncReceiveComplete(IAsyncResult result)
at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.SecurityChannelListener`1.ReceiveItemAndVerifySecurityAsyncResult`2.InnerTryReceiveCompletedCallback(IAsyncResult result)
at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously)
at System.ServiceModel.Channels.InputQueue`1.AsyncQueueReader.Set(Item item)
at System.ServiceModel.Channels.InputQueue`1.Dispatch()
at System.ServiceModel.Channels.InputQueue`1.OnDispatchCallback(Object state)
at System.ServiceModel.Channels.IOThreadScheduler.WorkItem.Invoke()
at System.ServiceModel.Channels.IOThreadScheduler.ProcessCallbacks()
at System.ServiceModel.Channels.IOThreadScheduler.CompletionCallback(Object state)
at System.ServiceModel.Channels.IOThreadScheduler.ScheduledOverlapped.IOCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.ServiceModel.Diagnostics.Utility.IOCompletionThunk.UnhandledExceptionFrame(UInt32 error, UInt32 bytesRead, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
So I removed my BOLayer assembly from the GAC to continue trouble shooting. Running File Montior, the last thing that happens (at least that I can understand from the trace), before w3wp.exe invokes DW20 to report the unhandled error, is it looks for the BOLayerin the GAC, and c:\windows\inetsrv, it does not look in the path that corresponds to the virtual directory the WCF service is running in. Looking at other parts of the filemon trace, I see my other assemblies being queried successfully (first check in the GAC, and when not found there, check the local path).
Update:
Upon further googling, I came across a post of MSDN forums where the author talked about a similar problem and thought it was related to hotfix KB928365. In addition to the dev server I was working on, I had another server that still had the older version of all the assemblies on it. Testing against that server, I got the same behavior, indicating that it was not a problem with CSLA, or my code. There was an Add/Remove entry for the 928365, so I uninstalled it on the server that has the newest version of my code to test it's effects, and I no longer have the problem. I don't know where to go from here, except to hope there's a revised hotfix sometime soon.
Copyright (c) Marimer LLC