Migrating large app from CSLA 5.5.4 to 9.1.0

[bdeluard]

Hello!
I'm on the road to migrate a large application from 5.5.4 to 9.1.0, with a wpf client app and a remote csla server accessing data with sql.

I have read all docs founded, find solutions for client (like suggested in doc with a global IServiceProvider, and regenerating my base code of business classes after modifying Codesmitrh templates. Globally quick and simple!

For the server, where I have may business work, in objet classes or uow classes, the problem is greater! With the new problem of injecting a IDataPortalFactory, the only solution is to add a parameter to all "old" static methods to instanciate objets. I do a minimal part to access the menu of the wpf app.

I changed also the security architecture, but keeping the principle to transmit a token (string) from the wpf client to the server by the use of an entry in the ClientContext. All is ok, the app initialize by execution of a Fetch method of an uow (Commandbase), collecting data on the server and returning to the app th show the shell. A second uow extracts correctly some stats data to show them.

After, when I try a - simple - option, to read a param data with a business object and a Fetch method, the ClientContext on the server comes without the token (and a second parameter without importance) : the dictionary is empty, and so, app will crash...

In the past, I had problems with ClientContext in version 5.x, which were resolved. I see in the forum that problems arised with Blazor, but I'm in wpf.

I traced the call in debug mode, but it's a little complicated due to the complexity of the csla code :)

Can anybody have an ide og the problem or a direction to search?

Here is the method for configuring csla in the wpf app :

using System;
using System.Net.Http;
using System.Security.Claims;
using System.Security.Principal;
using Csla;
using Csla.Configuration;
using Csla.Core;
using Ffsa.Data.Csla;
using Microsoft.Extensions.DependencyInjection;
using static Csla.ApplicationContext;

namespace Ffsa.Apps.Wpf.Shell.Infra
{
    public static class ConfigCsla
    {
        public static void Execute (string url, string jeton, int timeout)
        {
            var services = new ServiceCollection ();
            services.AddTransient<HttpClient> ();
            services.AddCsla (o =>
            {
                o.AddXaml ();
                o.BindingOptions.PropertyChangedMode = PropertyChangedModes.Windows;
                o.Security (so =>
                {
                    so.FlowSecurityPrincipalFromClient = false;
                    so.AuthenticationType = "Windows";
                });
                o.DataPortal (dp =>
                {
                    dp.AddClientSideDataPortal (opts =>
                    {
                        opts.UseHttpProxy (opts =>
                        {
                            opts.Timeout = TimeSpan.FromSeconds (timeout);
                            opts.ReadWriteTimeout = TimeSpan.FromSeconds (timeout);
                            opts.DataPortalUrl = url;
                        });
                    });
                });
            });
            CslaServicesGlobaux.ServiceProvider = services.BuildServiceProvider ();
            var ApplicationContext = CslaServicesGlobaux.ServiceProvider.GetService<ApplicationContext> ();

            ApplicationContext.User = new ClaimsPrincipal (
                new ClaimsIdentity (
                    WindowsIdentity.GetCurrent ()
                )
            );

            // enregistrement du jeton pour la vie de l'application
            ApplicationContext.ClientContext.Add ("Jeton", jeton);
            ApplicationContext.ClientContext.Add ("Poste", Environment.MachineName);
        }
    }
}

Thanks in advance,

Bruno

[StefanOssendorf]

Hi @bdeluard !
To understand you correctly: Executing commands work as expected but not a simple Fetch of another business object (BusinessBase or BusinessListBase)?
Could you show the calling code for that fetch?
Do you maybe create a new dependency injection scope from which you execute the fetch on the client? If so, the data are not there because the ApplicationContext has a scoped lifetime.

The configuration above looks good to me though.

[bdeluard]

Thanks for your answer.

In fact, my summary is quite nebulous... The first call after config csla on wpf client is a uow (derived from CommandBase) to do authentification and having shell data in return. For that use case, the token is transmitted in a parameter of the commande.

For all subsequent calls (business objets and commands) the token is normally transmitted in an entry of the ClientContext.

If I have undestand, in wpf, there is only one "ApplicationContext" instance, and so I have to add the token in the property ClientContext only one time? and that's what I do in the config of csla ? And it's allways the same ApplicationContext used to instanciate portals ?

On the wpf side : I replace the static "DataPOrtal" by a new class called "DataPortal" with the same methods like static old version, which use the global service provider to access a instance dataportal :

• the static method in the business object class to fetch data by int key :

public static async Task<TechParamInfo> ChargementAsync (int id)
{
    return await DataPortal.FetchAsync<TechParamInfo> (id);
}

• the DataPortal class :

public static class DataPortal
{
    //...
    public static async Task<TP> FetchAsync<TP> (params object[] crit)
    {
        IDataPortal<TP> portail = CslaServicesGlobaux.Portail<TP> ();
        return await portail.FetchAsync (crit);
    }
}

• the "CslaServicesGlobaux" static class initialized in the config phase of csla (previous code) :

public static class CslaServicesGlobaux
{
    /// <summary>
    /// Fournisseur de services pour l'injection de dépendances
    /// </summary>
    public static IServiceProvider ServiceProvider { get; set; }

    /// <summary>
    /// Contexte applicatif de CSLA
    /// </summary>
    public static ApplicationContext ApplicationContext         
    {
        get { return ServiceProvider.GetRequiredService<ApplicationContext> (); }
    }

    public static IDataPortal<T> Portail<T> ()
    {
        return ServiceProvider.GetRequiredService<IDataPortal<T>> ();
    }
}

I hope this is more clear....

Bruno

[rockfordlhotka]

I am assuming that CslaServicesGlobaux is a static class with a static property for ServiceProvider, and that you are using that to get instances of ApplicationContext when you need them?

In pre-DI WPF, nothing automatically maintains any instance of ApplicationContext unless you do it in a static field - or unless you maintain a static field for ServiceProvider and keep asking that for the ApplicationContext (because ApplicationContext is "owned" by the ServiceProvider).

[bdeluard]

Yes, CslaServicesGlobaux is a static class, which contains an ApplicationContext member (called CslaAppContexte) and an IDataPortalFactory instance (called DataPortalFactory), that are used to instanciate portals in the static methods of my bisiness objetcts.

Since last time, I have done some modifications. My static methods are like this one for feching a instance :

public static async Task<TechParamInfo> ChargementAsync (int id)
{
    return await CslaServicesGlobaux.Portail<TechParamInfo> ().FetchAsync (id);
}

and the static method is like this :

public static IDataPortal<T> Portail<T> ()
{
    if (CslaAppContexte.ClientContext.Count == 0)
    {
        CslaAppContexte.ClientContext.Add ("Jeton", Jeton);
        CslaAppContexte.ClientContext.Add ("Poste", Environment.MachineName);
    }
    return DataPortalFactory.GetPortal<T> ();
}

At execution, at the beginning of the work, the client context contains the 2 fields created at the startup with the code previously showned. I added code to test if the client context has these properties and, if empty, added them (I needed to add a new member in the static class). After that, all calls are correctly executed in the remote server, because the token is well transmitted.

I think it's not a good solution, but it works :)

Are we sure that there is only one ApplicationContext ? and what if the Fetch method is called on a separate thread ? Because it seems that the ClientContext is cleared for some reason I can't find...

Thanks your for your advices,

Bruno

[StefanOssendorf]

The setup itself looks okay to me.
WPF has typically only one DI-Scope which provides everything necessary for the application. So there should only be one ApplicationContext.

Maybe the issue is the underlying AsyncLocal field which saves the client context. Maybe it get's "cleared" due to the context switches? I'm not very knowledgable about the AsyncLocal type. So maybe someone can help?

Your workaround isn't an ideal solution but it works for now. We should investigate that on our end.

On a personal note, here's another recommendation:
If you are using the async data portal operations with the corresponding attributes you should take a look at: https://github.com/StefanOssendorf/Csla.DataPortalExtensions
My lib generates type & compile safe extensions so the compiler can help you identify broken usages.

[StefanOssendorf]

We still have an ApplicationContextManagerStatic. So if you want you could give it a shot if it helps:
After adding csla to the DI you have to call services.AddSingleton<IContextManager, ApplicationContextManagerStatic>().
This will add the static manager as default manager and hopefully this one will retain the client context correctly. You now just have to be aware that the state is truly shared and not AsyncLocal anymore.
It's just an idea. I don't know if it's actually working.

[bdeluard]

Moving forward on migration, I am to the stage to test DynamicRoot.List business objects. Truly, they needs some adjustments. First, I see that updating (when changing line in a grid) triggers execution on the remote server an operation of... insert ! But, before, that, I see that the operation is triggered inside CSLA code, and my workaround to refresh the token in the ClientContext is not called : so the remote operation can't be executed.

It was the time to test your last suggestion, using the static context manager. I tried that a coupmle of days ago, but I had not the right methode. Using your proposal, I added the line "services.AddSingleton<IContextManager, ApplicationContextManagerStatic>()".

This resolve the problem ! I tested another time all csla calls that needed to refresh the token in the CLientContext, and now there is no time where the dictionary was cleared.

For me, the static context manager is the solution.

Thanks for all your advices, I can continue my migration.

Bruno

[StefanOssendorf]

I'm glad I could help :)