I've created a WCF service that has a method that performs several things including async calls to populate a few CSLA collections.
I store a value in Csla.AppicationContext.ClientContext that is used in my DAL.
What I have occuring is that in my WCF service method, at least the first call to a CSLA object the ApplicationContext is correct, but on a call to a later CSLA object the ApplicationContext has been cleared.
I've followed what was written in the CSLA 2008 book to include the CredentialValidator and PrincipalPolicy classes which seem to work great because I always have the correct Principal throughout all the calls in my service method. I've installed the Nuget package of csla-core and csla-web.asp.net.
I'm looking for a way to retain the Csla.ApplicaitonContext within my various CSLA calls in my WCF service method.
EDIT
I've discovered that by removing the csla-asp.net nuget package -- which removes the CSLA.Web dll -- it now works. I was under the impression that CSLA.Web was necessary to for CSLA.ApplicationContext to be correct?
The correct behavior for Csla.ApplicationContext in a service is to clear the values between calls.
If you want to share instances of CSLA collections in your code you should use some other explicit caching mechanism (like AppFabric or MemoryCache) or store the lists in your own dictionary.
I thought that meant that Csla.ApplicationContext was cleared between calls TO the service, not withing the service. What I'm talking about is this:
public async Task MyWcfServiceMethod(int id)
{
var root = await Foo.GetEditiableRootAsync(id);
// Csla.ApplicationContext is cleared here?
var collection = await Bar.GetReadOnlyListAsync(root.Id);
}
I was finding the Csla.ApplicationContext was getting cleared within the call to the method.
I believe this is because Tasks and their continuations are not guaranteed to execute on the same thread, hence you are loosing thread context. If I remember correctly, referencing Csla.Web should address the problem and force CSLA to use HttpContext.Current to store the data. Do you have Csla.Web in the bin folder?
I started with Csla.Web in my bin folder by including the Nuget package CSLA-ASP.NET because I had read that Csla.Web will correctly handle the Csla.ApplicationContext. Yet, it wasn't working.
Out of desperation, and because of this post http://forums.lhotka.net/forums/p/11988/55578.aspx#55578
I removed CSLA-ASP.NET (which removes the Csla.Web file) and now things are working. I'm still concerned because the fix for the problem I was having (including Csla.Web) is the very thing that seemed to cause the problem.
This means that your ApplicationContext is stored in thread context instead of HttpContext . As a result, your issue might resruface if you land on a different thread. I would encourage you to do a lot more testing before saying the issue is solved. I think Csla.Web should work for you. You may have to download the source of csla, compile locally and see why HttpContext storage of application context is not working.
I've been testing it all day and what I've found is that in my WCF Service, after I make an async data portal call to a CSLA object, it returns and HttpContext.Current is then reset to null. This is with Csla.Web included in the project.
What I later tried was I created a test project that only includes the essence of the problem. This WCF process behaves when CSLA.Web is NOT included, but when it is included it has a slightly different -- but I'm certain related -- problem then my main project: it doesn't seem to handle the Principal correctly.
I've put my minimal test probject up on Github for anybody who cares to take a look at it. Perhaps I've got the Web.config wrong in my data portal or my WCF service?
Hi,
WCF wil not use the ASP.NET Pipeline unless unless you explicitly change the AspNetCompatibilityRequirements to Required or Allowed.
See: http://blogs.msdn.com/b/wenlong/archive/2006/01/23/516041.aspx
Csla.Web only makes sense to include in apps/services that use the ASP.NET Pipeline (and HttpContext).
Thanks Jonny. So, what I think this means is that since I'm using custom authentication that I need to use WCF in aspNetCompatibilityEnabled="true" and then decorate my WCF method so that the AspNetCompatiblityRequirements are set to Allowed. Once that is in place, I can include Csla.Web.
If aspNetCompatibilityEnabled is set to false then, according to that blog post, you lose the ability to use HttpContext.Current which I believe is something I need because I'm using Csla.ApplicationContext.ClientContext.
Frustratingly, I have done this and inlcuding Csla.Web causes Csla.ApplicationContext to clear after a call to my data portal.
I'll continue to look at this, but I think this is coming down to WCF with CSLA is my kryptonite. I previously failed to get a Azure WCF data portal to work with a winforms app, I had also had more trouble than expected getting a website to access another data portal, and now I'm wrestling with a WCF service that works when it shouldn't.
Copyright (c) Marimer LLC