Very strange problem ClientContext data loss

[angtianqiang]

@rockfordlhotka I tested a very strange question

I tested a very strange question Running environment: WPF netcore3.0 csla5.0.1 Problem description: set the ClientContext value in the WPF start window and read it as null, while it can be read normally in the non-wpf main window. This problem has not occurred before with WPF (net4.0)+csla4.7.2, can you help to see what is going on

Test code:

public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); Csla.ApplicationContext.ClientContext["a"] = "test"; }

private void Button_Click(object sender, RoutedEventArgs e)
{
    var aa = Csla.ApplicationContext.ClientContext["a"];
    //   aa = null;
    //This is in the main window and reads null
}

} public partial class Window1 : Window { public Window1() { InitializeComponent(); Csla.ApplicationContext.ClientContext["b"] = "test"; }

private void Button_Click(object sender, RoutedEventArgs e)
{
    var bb = Csla.ApplicationContext.ClientContext["b"];
    //  bb = test"
    //This is the non-wpf main window and can be read normally
}

}

[rockfordlhotka]

I suspect this is due to a breaking change we made a while back, switching to AsyncLocal to manage context instead of thread local storage (TLS).

https://github.com/MarimerLLC/csla/issues/729

When using AsyncLocal the CSLA context flows with the .NET synchronization context, not necessarily with the thread. As a result things act more "normal" for .NET, but are absolutely not the same as before, because if the thread switches between different synchronization context (UI context) environments then the CSLA context doesn't flow across those boundaries.

A workaround is to take the ApplicationContextManager that does use TLS and configure CSLA to use your custom context manager on app startup. That'll switch back to the TLS behavior instead of the newer AsyncLocal behavior.