in my WPF applications start method the Csla.ApplicationContext.User is setup with a custom principal/identity instance.
Later this will be queried on a background thread from the thread pool, but there the property is set to Csla.Security.UnauthenticatedPrincipal.
The background thread is invoked using Task.Run(() => toDo());
I am using Csla 220.127.116.11
The WPF handling is as follows: (make sure Csla.Xaml.dll) is referenced and included with your app)
So when you run a background task it is your responsibility to make sure that the custom user principal is transferred to that thread.
Csla.Threading.BackgroundWorker.cs will handle do this for you. I have not digged into how this may be handled for Tasks.
Tasks run on a background thread from the thread pool. Because they are a different thread, thread-specific context (like the principal) doesn't automatically follow onto those threads.
The Csla.Threading.BackgroundWorker automatically spins threads onto the thread pool with all the primary thread's context.
Also, the WPF, Silverlight, WP7, and WinRT User properties are implemented as static behind the scenes, so they should automatically follow onto all threads in the AppDomain. Other context values won't necessarily follow automatically (I don't remember the behavior for certain - check the 'Using CSLA 4' books or the code in svn for details).
Copyright (c) Marimer LLC