It seems that the content of ApplicationContext.ClientContext disappear . During the login proess i put the user id in the clientContext, then i use my implementation of IAuthorizeDataPortal to recreate the user and get the stuff i need from it. Now this is working fine for a couple of back and forth and than suddenly no more userID in the ClientContext, this can happen at any time, i there seems to have no pattern.
By reading the previous post, a recurring anwser is make sure you have the csla web in the folder, and i do.
i'm using Win8 with CSLA Core.4.5.30. on .net 4.5
Which UI technology do you use?
Hi,
For WPF you must make sure that Csla.Xaml.dll is present in your bin folder.
We are using XAML C# on Windows 8 and we do have CSLA.xaml.dll in the .Net for Windows Store Apps
When i say windows 8 i mean Windows Store Apps and we do have the csla.xaml in the Windows Store App referecnces
Is the ClientContext being lost on the client, or is it just not making it to the server via the data portal?
seems to have been lost on the client as well :-\
it seems to be happening only or more during development then when running the application.
In WinRT the application context values are stored in a static fields, so they are global to the app. This does mean that changes to the values on background threads are global to the app. It also means that if the appdomain is reset somehow that the values would be lost. I don't know how _that_ would happen in WinRT though.
Hi,
I kinda suspect there is at least 2 other possible explanations as having applicationcontext in static variables breaks the DataPortal logic for SetContext / ClearContext when running in local mode.
1. Making 2 async DataPortal calls in parallel will make the second call start with ExecutionLocations.Server and then call ClearContext when complete.
2. Calling f.ex a new DataPortal.Fetch method from within another DataPortal.Fetch will make the second call start with ExecutionLocations.Server and then call ClearContext when complete.
You are probably right. And there's no easy solution because we have no access to TLS or ExecutionContext. As a result I do have an issue in the backlog on GitHub to develop my own equivalent to ExecutionContext for use in WinRT. I guess the priority of that issue should be elevated...
Been digging into the code and it does not seem to be the issue.
There is an extra check for context.IsRemote before the ApplicationContext.Clear() so I am not able to recreate the issue.
after all these years 
, i'm still having the issue, as you said JonnyBee it seem to be happening a lot more when i do a DataPortal.Fetch inside another DataPortal.Fetch but it is very strange, as it does not happen all the time and at the same place????
By digging a bit more it seem to be happening when there is more than one Dataportal call coming from the WinRT app at some point it looses the ApplicationContext.ClientContext in the backend ????
Digging more into this issue i realized that CSLA seems to be dropping the ClientContext when calling a DataPortal inside another DataPortal
For Example:
Client Code
Csla.ApplicationContext.ClientContext[Key] = "SomeData"
Csla.ApplicationContext.ClientContext[Key2] = "SomeOtherData"
DataPortal.Fetch(some criteria)
Server Code
DataPortal_Fetch(some criteria)
{
Csla.ApplicationContext.ClientContext has 2 item
Get Data from a database
DataPortal.FetchChild<someChildObject>(some criteria));
}
SomChildObject()
{
private void Child_Fetch(somecriteria)
{
Csla.ApplicationContext.ClientContext is empty (Sometimes)
}
Anybody seen this before?
Hi,
Are you sure the ClientContext is till present after data access from database?
If you have async or tasks in the data access that would explain how the code could be running on another thread and hence has lost the application context.
DataPortal.FetchChild does NOT use task or async and does not interact with ApplicationContext.
The semenatics of DataPortal.FetchChild is:
Another culprit may be if you have async/tasks in one of the other methods that may be called.
Givin that how do I get it back? I need the clientcontext all the way down to the DataPortal.FetchChild
I do have Async Tasks in some methods and I do need the client context, can I do something to keep it?
The clientcontext is attached to the primary thread. If you somehow make a call that ends up running on another thread it is up to you to copy the clientcontext from the original thread to the new thread.
A typical async/await call won't actually jump threads btw - but if you do Task.Run or something along that line the result would be a new thread.
I'm Only using Async/Await and by adding the CSLA code to MY project to see what's going on, I see that at the beginning of the CSLA stack the ClentContext is there but than a bit later it disappear for some reason.
I'll send some screen shot that shows what Im sayingHi,
Do you use the Csla.Threading.CslaTaskScheduler when you run tasks?
As you can see in the picture I do have the ClientContext.
Here is the steps
1. I use DataPortal_Fetch to get my Invoice
2. I Add a Part on it, doing this triggers an Async Business rule
2.1 That calls a DataPortal_Execute (a Command)
2.2 That command Load the part again (DataPortal_Fetch) but this time in edit mode so it can set some missign attributes
When I'm Loading the properties of the last Fetch - The context is lost,
In the picture included here you can see the CSLA call stack.
Am I doing something wrong?
I'm using a lot of Async business Rules and it seems to be happening more in them!!!
All your code (1 through 2.2) is 100% server-side?
1. Is from the UI , It call the server to get the list of Invoices
but the rest is all server side.
So your Part object is a child of something like Invoice.PartList, but is also a root object in that it has a DataPortal_Fetch method (not just a Child_Fetch)?
Also, is the async rule that is run in the Part object a per-type or per-property rule? What triggers this rule to run when the object is created?
These rules are per-property rules.
We use BusinessRules.CheckRules(PartTypeProperty);
So it loads a list immediately for the user to select, to set another property.
So you use use a rule to do lazy loading of a property?
The setting of a property load a list for the user to be able to set another property.
Property A is set -> triggers a rule to load the possible choices for Property B
Hope that clarifies
I'm not sure I see how this scenario gets you to loading a child object as a root? What do you do, load it, pull the collection from it, and then discard it?
Why not just load the filtered collection directly?
As I start to move the forum to GitHub, I'll move active threads there via link. Here's the link to continue this thread:
That's right, we use it as both a child and a Root object.
Copyright (c) Marimer LLC