It looks like we have a nasty problem with ApplicationContext which I am hoping someone can help with.
We have some WCF services hosted within an ASP.NET website (where the website also contains ASPX pages) so that we can expose data to JavaScript for client-side functionality (such as auto-complete dropdowns.) All of the WCF services have AspNetCompatibility set to Required so that we can access Session contents. We're using IIS 7.5 to host the website and Csla 4.1 with .NET 4.
Csla.Web is in the \Bin folder so that we are using the HttpContext-based ApplicationContentManager.
Most of the time everything works just fine, but every once is a while our WCF services stop working. After patient debugging it appears that we end up with Csla.ApplicationContext.User returning the wrong principal (not our custom principal), so all of our authorisation then fails. This problem remains until we restart the AppDomain, when everything starts working normally again.
Having looked at the Csla implementation of ApplicationContext it is clear that the ContextManager property could cause us problems. It appears that on each request the IsValid property of the current IContextManager is checked and if IsValid returns false a new instance of the non-web ApplicationContextManager is created. In Csla.Web the ApplicationContextManager.IsValid property checks whether HttpContext.Current is null. If this were ever to happen then Csla would switch to the wrong ApplicationContextManager and this would not be corrected until the AppDomain restarts.
I have no idea why HttpContext.Current would ever be null, unless it is to do with the fact that we are using async service methods for some of our services to support best scalability. At the moment it is a guess that this is happening, because the problem doesn't occur regularly we have difficulty debugging it fully.
Has anyone else ever seen this problem and did they come up with a solution? Thanks.