Vibrant discussion about CSLA .NET and using the framework to build great business applications.
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?
Jonny Bekkum, Norway
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.
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 ????