CSLA Configuration and ASP.NET Core

[j055]

I'm finding some of the CSLA configuration in an ASP.NET Core app a little confusing:

1. Blazor - there's a Csla.Blazor.ApplicationContextManager in the Blazor project but it only seems to be used by client-side Blazor. I'm thinking we may need a context manager specifically for server-side Blazor to handle some of the issues raised here. In which case would it be better in the Csla.Blazor.WebAssembly project? It might be worth considering a new project for SSB, e.g. Csla.Blazor.Server, to put only the SSB stuff.
2. There's an extension method which deals with core CSLA services: services.AddCsla(). The extension method is in the core project so it doesn't register the 'Csla.AspNetCore.ApplicationContextManager' context manager. Instead a singleton is created by another extension method in Startup.Configure (app.UseCsla()). It would be better added to the service collection: services.AddSingleton<IContextManager, Csla.AspNetCore.ApplicationContextManager>(); ideally inside services.AddCsla() (but that would have to be moved into the Csla.AspNetCore project). Unless you added another extension like services.AddCsla().WithAspNet() or moved ASP config into it's own namespace. It’s a bit ugly though!

What do you think? I'd appreciate your comments/suggestions as always.

[rockfordlhotka]

Another thing to consider is that SSB can co-exist with Razor Pages, MVC, and web API code. To me this implies that two different sets of config and state might be required: one for SSB and another for the rest of the aspnetcore code running "in the same context".

Sounds like a mess to me!

[j055]

HttpContext is out for sure!

[rockfordlhotka]

OK, now I read the article - so not AsyncLocal, but rather a private field in App, or a scoped instance of an object using DI.

So we need

1. a context manager for SSB that stores context appropriately
2. enhancement to ApplicationContext itself so it is possible to have more than one context manager in a given "appdomain" context

That second part is what'll need some thought.

[rockfordlhotka]

The thing is, the timing for this is pretty good. It was already not clear to me that, in CSLA 6, ApplicationContext could continue to be a static class.

Specifically #1068 can probably address the issues we're discussing here, plus the original unit testing issues I wanted to address - but it probably also means ApplicationContext won't work at all like it does today.

[j055]

Some sort of clever context switching. Can ApplicationContext know if it's being accessed over a SignalR connection? Sounds nasty.

[j055]

#1068 sounds like a better approach though.