CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • wpf app losing Csla.ApplicationContext.User

    rated by 0 users
    Answered (Verified) This post has 1 verified answer | 6 Replies | 3 Followers

    Not Ranked
    12 Posts
    kosta_t posted on Mon, Nov 21 2011 2:26 PM

    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?

     

    Answered (Verified) Verified Answer

    Top 10 Contributor
    9,475 Posts

    Also, in a WPF client, you must reference Csla.Xaml.dll so you get the correct ApplicationContext.User provider for WPF.

    Rocky

    • Filed under:

    All Replies

    Top 75 Contributor
    114 Posts

    kosta_t:
    The app does use background threads.

    The explanation of Jonny in  "problems with ClientContext being cleared" might be helpful.

     

    Top 10 Contributor
    2,279 Posts
    JonnyBee replied on Mon, Nov 21 2011 11:32 PM

    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.

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 10 Contributor
    9,475 Posts

    Also, in a WPF client, you must reference Csla.Xaml.dll so you get the correct ApplicationContext.User provider for WPF.

    Rocky

    • Filed under:
    Not Ranked
    12 Posts

    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

    Top 10 Contributor
    9,475 Posts

    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.)

    Rocky

    Not Ranked
    12 Posts

    Thanks, that was it.

    Referencing Csla.Xaml.dll from the application (.exe) fixed the problem.

    Page 1 of 1 (7 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems