Hi,
I am porting an app from csla v3.8 to v4 (4.2.0-111004). The (development) app combines client & server in a single exe.
I have a custom principal class (similar to PTPrincipal) which worked as expected with v3.8. However in 4.2 the application 'loses' the principal shortly after a successful login.
The app does use background threads.
Any clues as to what I should be looking at?
The explanation of Jonny in "problems with ClientContext being cleared" might be helpful.
Hi,
In short:
1. Make sure that your app use Csla.Threading.BackgroundWorker and not System.ComponentModel.BackgroundWorker
2. Make sure that Csla.Web.dll is not in your bin folder.
3. Make sure that Csla.Xaml.dll is in your bin folder.
The referenced post is for a web application that need Csla.Web.dll to be present in bin folder.
Also, in a WPF client, you must reference Csla.Xaml.dll so you get the correct ApplicationContext.User provider for WPF.
Hi,
thanks for the reply
the 'development' app is a single WPF application combining both client & server components. It is composed of several dlls (eg csla level, WPF level, data level etc)
CSLA.xaml.dll is referenced by the WPF dll, but not directly by the exe itself.
The WPF dll aslo uses System.Delegate.BeginInvoke.
The same code (async calls & custom Principal) was working fine with CSLA 3.8.x
The difference between 3.8 and 4 is that the WPF User provider was in Csla.dll in 3.8, and it is in Csla.Xaml.dll in 4. Your WPF application must reference Csla.Xaml.dll so the .NET type loader can find the correct provider.
(we pulled all UI-specific code from Csla.dll in 4, so the core framework has no dependencies on any of the UI technologies - necessary to support mono, as well as to position us for WinRT, etc.)
Thanks, that was it.
Referencing Csla.Xaml.dll from the application (.exe) fixed the problem.
Copyright (c) Marimer LLC