Please reopen 'Replace use of ApplicationContext with injectable config object'

[j055]

My heart sank when I read your conclusion. I definitely think it would be worth the effort to make 'ApplicationContext' or some other newly named type injectable.

#1068

You say that

The big problem is that there are quite a number of reflection helpers in Csla.Reflection that rely on configuration options,

Would it be possible to leave that stuff alone for now and just remove, the static IContextManager to allow that to be injectable (and related properties)?

I'm specifically interested in getting CSLA and Blazor Server-side working but this would also help with testing and removing a dependency on things like HttpContext seems like a good thing.

I think the priority has to be to get Blazor SS working ASAP because it's supposed to work according to 'Using CSLA 5
Blazor and WebAssembly'!

Thank you

[rockfordlhotka]

I did spend some serious time trying to follow my vision here, but the work is prohibitive, as are the breaking changes.

Don't conflate the ApplicationContext injection issue with support for server-side Blazor and HttpContext. The IContextManager is different for many runtimes, and now that I understand that HttpContext isn't valid in SSB it is clear that a new context manager is required to track against the circuit.

Fortunately I wrote a prototype chat app quite a while ago, so I have some insight into how to create shared state against a circuit.

[j055]

I did a search on 'ApplicationContext' in the CSLA code and got over 1200 hits! The staticness of the ApplicationContext class is far from ideal but I can appreciate changing it is going to be a lot of work and there are going to be breaking changes for sure!

What about creating a new IUserContext which would deal with User, LocalContext, ClientContext? Configuration stuff is OK bound to the app domain. Bit of creative find/replace of the following:

ApplicationContext.User = 71 hits (17 are in Sliverlight!) becomes userContext.User
ApplicationContext.ClientContext = 36 becomes userContext.ClientContext
ApplicationContext.LocalContext = 81 becomes userContext.LocalContext

Then access the IUserContext through the ServiceProvider in the relevant classes. I'm sure there's some other important stuff I've overlooked!

I'm glad you've got a solution to the SSB problem anyway. CSLA and Blazor are such a good fit it's worth getting right. Thanks for looking into it.

[rockfordlhotka]

The big challenge is actually quite deep, and something I didn't expect - which is that a whole lot of code in Csla.Reflection relies on configuration values from ApplicationContext. And ApplicationContext relies on code in Csla.Reflection. I struggled to tease those apart, and that's where I basically threw my hands in the air and said it wasn't worth the effort 😢

The problem is that nearly all uses of reflection framework-wide go through Csla.Reflection (as they should). And Csla.Reflection mirrors a lot of normal .NET reflection - meaning most of the calls are to static methods. Yet the implementations rely on ApplicationContext because that's where the magic happens - the intersection of config and the type system.

So it ends up being a tricky thing - if the context/config is injected, then you can't use static methods for reflection either - the type system/reflection support also needs to be injected. And that means touching every part of the framework code that calls Csla.Reflection and rewriting it to require an injected type system rather than the current static methods.

[j055]

OK thanks, I hadn't realized reflection was still such an important part of CSLA.

[rockfordlhotka]

@j055 I know you were disappointed - but now you can rejoice, because I reopened the issue and have made substantial progress 🚀