Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I'm a long time CSLA developer, but have been using CSLA 2.x for a LONG time. Just now trying to get up to speed with the latest versions (4.3.12). Was going to build a little sample app using asyc methods, but right away hit an issue when trying to use async login method with custom Principal/Identity.
The attached is a super simple app which shows the problem. If you click the login button you'll see it properly sets authenticates and Csla.ApplicationContext.User is authenticated and has the proper custom principal, but after that, click the other button and it shows it is no longer set.
Basically, I have code like below to detect when user changes. Within here the user is correct but everywhere else it is still the default principal and not authenticated.
FormPF.BL.Security.PTPrincipal.NewUser += () =>
// here Csla.ApplicationContext.User is authenticated and
// is the custom principal
If I stop using BeginLogin (the async method) and just do regular Login, all works as expected. I'm very new to async, any ideas what I'm doing wrong?
.NET stores the user principal/identity at the thread level. So if you set the principal on a background thread it will have no impact on the main UI app thread.
Also, WPF works very hard to prevent the principal from being changed, even on the main app thread, so if you are using WPF that will also complicate matters.
CSLA tries to help overcome some of these issues. The data portal async callback will normally run on the main app thread (though not automatically in console apps or unit test scenarios because they don't set up .NET synchronization contexts). And if you reference Csla.Xaml.dll for WPF, then Csla.ApplicationContext.User will overcome WPF's resistence to setting the principal.