Losing ClientContext calling DataPortal from within ASP.NET Core

[hurcane]

I'm working on a proof of concept using a Console project and I am trying to implement a remote data portal following the model of the Project Tracker sample, but using the object factory model. In my use case, the object factory Fetch method calls CheckRules, and one of the rules being executed calls DataPortal.Fetch on a different object.

When debugging iisexpress, a breakpoint in the rule, just before it calls the DataPortal.Fetch, shows ClientContext settings that were passed from the console project. A breakpoint in the second object's Fetch method have an empty ClientContext.

I originally had the problem on 5.1.0, but have upgraded to 5.3.2 and still have the problem. This is all running on Windows and using VS2019.

If I uncomment app.UseCsla from the host startup configuration, the client context is available from the object being instantiated by the rule. My real question is whether I am going to get in trouble by not calling app.UseCsla.

The workflow from a high-level perspective

• Console calls DataPortal.Fetch
• UserEdit object factory is instantiated inside ASP.NET Core and Fetch method called
• Fetch method calls CheckRules
• Rule calls DataPortal.Fetch (DBConnection value from ClientContext is defiend)
• CodeValdation object factory is instantiated inside ASP.NET core and Fetch method called
• DbConnection value from ClientContext is null

The console class Main method:

        static void Main(string[] args)
        {
            CslaConfiguration.Configure().
                PropertyChangedMode(Csla.ApplicationContext.PropertyChangedModes.Windows).
                DataPortal().DefaultProxy(
                    typeof(Csla.DataPortalClient.HttpProxy),
                    "http://localhost:16618/api/dataportal/");

            Csla.ApplicationContext.ClientContext["DbConnection"] = @"Server=DBSERVER\DEV12;Database=POCCsla5;Trusted_Connection=True;";

            var user = DataPortal.Fetch<UserEdit>("DVB");
            Console.Write("press any key to exit...");
            Console.ReadKey(intercept: true);
        }

Relevant parts from the ASP.NET Core host:

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            } else
            {
                app.UseHsts();
            }

            app.UseMvc();

            ConfigurationManager.AppSettings["CslaObjectFactoryLoader"] =
                "POCCSla5.DataAccess.DalFactoryLoaderPOCCSla5.DataAccess";
            ConfigurationManager.AppSettings["ObjectFactoryAssembly"] = "POCCSla5.DataAccess.Sql";

            app.UseCsla(); // Works when commented out.
        }

Execute method from the rule

        protected override void Execute(IRuleContext context)
        {
            var codeType = (string)context.InputPropertyValues[_codeTypeProperty];
            var codeValue = (string)context.InputPropertyValues[PrimaryProperty];
            var validation = DataPortal.Fetch<Util.CodeType.CodeValidation>(
                new Util.CodeType.CodeValidation.Criteria(codeType, codeValue));
            if (!validation.IsValid)
            {
                var errorMessage = validation.InvalidCodeReason;
                if (string.IsNullOrWhiteSpace(errorMessage)) errorMessage = $"{codeValue} is invalid.";
                context.AddErrorResult(errorMessage);
            }
        }

[rockfordlhotka]

I believe this is the same issue as #1790, and the direct workaround/solution is to use the ApplicationContextManagerTls instead of the default context manager.

[rockfordlhotka]

Right now the workaround is ApplicationContextManagerTls, but there is a backlog issue to figure out how to get the context to flow with the AsyncLocal context manager as well: #1875

[hurcane]

So I tried a line like this in Startup .cs of the ASP.NET core host:

app.UseCsla((c) => c.ContextManager(new Csla.Core.ApplicationContextManagerTls()));

But this exhibits the same behavior. The key (DbConnection) becomes null after it goes through the local data portal and hits the Fetch method of the factory object.

Is this not the right way to use the alternate application context manager? I couldn't find any online examples of an existing project using the TLS manager.

What bad things might happen by not calling UseCsla at all when the host starts up? It makes my simple example work.

[rockfordlhotka]

I assume your ASP.NET host is ASP.NET Core?

In ASP.NET Core the HttpContext isn't globally accessible like it was in the past. and the web context manager used by CSLA requires HttpContext, and that means a line of configuration is required to make HttpContext available via DI.

So in your Startup.cs file there's the ConfigureServices method, and that method must include

      services.AddHttpContextAccessor();

I misread the original post and thought we were talking about a console app, but in an ASP.NET Core app the default web context manager should work fine - as long as HttpContext is available.

[hurcane]

Yes! I am modeling the general architecture based on Project Tracker, and it uses ASP.NET Core.

But... I started my proof of concept using version 5.1.0, and it doesn't have that line of code. 😶 I will be reviewing the current Project Tracker for other potential changes to look out for.

I really appreciate your help.