IHostedService calling DataPortal methods

[skeeler88]

I have configured Csla via Startup.cs in a ASP.NET Core 3.1 web application using Razor.

I set the context manager to be Csla.AspNetCore.ApplicationContextManager and everything works as expected throughout the website.

However when I register a IHostedService (it cannot access scoped services) because I need something to run every minute I get a null reference exception when calling DataPorta.Create

Is there a way to call DP methods independently ? (e.g. in this case there is no IHttpContextAccessor available or HttpContext; I just want a BO command to execute).

[rockfordlhotka]

What exactly is null? Can you provide the ToString of the exception?

[skeeler88]

I cannot tell exactly without stepping into Csla v5.2.1 I believe. It may even well be that I have Csla configured wrong.

Steps to reproduce:

I've tried adding ApplicationContextManager as Transient and Singleton to the IServiceProvider. Including ActivatorUtilities.CreateInstance method within the below config.ContextManager(...) method.

1. Create & configure a IHostedService (ConfigureServices) and within initial start up file. Configure method (DataPortal is set to a Local DP)

app.UseCsla(config =>
{
      config.ContextManager(serviceProvider.GetService<Csla.AspNetCore.ApplicationContextManager>()); // Singleton example
});

2. Create a Command e.g.

[Serializable]
public class CommandTest
        : CommandBase<CommandTest>
{

        [Create]
        private void Create()
        {
        }
}

3. Start website and it calls IHostedService.StartAsync(...):

public Task StartAsync(CancellationToken cancellationToken)
{
DataPortal.Create<CommandTest>(); // System.NullReferenceException here
return Task.CompletedTask;
}

Exception received:

{
   "ClassName":"System.NullReferenceException",
   "Message":"Object reference not set to an instance of an object.",
   "Data":null,
   "InnerException":null,
   "HelpURL":null,
   "StackTraceString":"   at Csla.DataPortal`1.Create(Type objectType, Object criteria)\r\n   at Csla.DataPortal`1.Create(Object[] criteria)\r\n   at Csla.DataPortal.Create[T](Object[] criteria)\r\n   at Csla.DataPortal.Create[T]()\r\n   at MySpecialNamespace.NotificationsHostedService.StartAsync(CancellationToken cancellationToken) in C:\\Etc.\\NotificationsHostedService.cs:line 51",
   "RemoteStackTraceString":null,
   "RemoteStackIndex":0,
   "ExceptionMethod":null,
   "HResult":-2147467261,
   "Source":"Csla",
   "WatsonBuckets":null
}

I presently implemented a workaround which included several POCOs, interfaces and the new keyword...

[rockfordlhotka]

If you can get the exception object you can call ToString on it (via code, or in the Immediate window) and that'll reveal the full stack trace, subexceptions, and ultimately exactly what's happening.

[skeeler88]

In Csla.AspNetCore.ApplicationContextManager because there is no HttpContext in a IHostedService.

I think I figured a workaround in the IHostedService to fake the HttpContext:

this.HttpContextAccessor.HttpContext = new DefaultHttpContext();

[rockfordlhotka]

OK, so from what I can find (such as https://forums.asp.net/t/2144171.aspx?Access+HttpContext+in+HostedService) the HttpContext is not supposed to be available to any IHostedService. Apparently that's a design choice in ASP.NET.

It looks like such a service should be registered as a transient service, and any services it requires should be injected into the service: dotnet/extensions#553

I think the issue with the data portal is that it is using an API to invoke dependency injection based on the service provider captured in Startup.cs - and that should be fine - except that the service provider instance is stored in ApplicationContext.LocalContext, and that (in turn) is stored in HttpContext - meaning it isn't available to the service, because HttpContext isn't available to the service.

This is something I'll need to keep in mind when implementing #1068 - and also I hope that #1068 ultimately helps address this issue.

I'm somewhat surprised that your workaround actually works, in that the service provider is captured in Startup.cs, and yet you are able to get at it again from your fake HttpContext. I wouldn't have expected that new context to have any values from the original Startup.cs configuration.

[skeeler88]

Further insight into the workaround you are right; we do need the service provider and that was the next exception I received. This fixed the issue (with all other needed objects injected). In particular IServiceScopeFactory

var httpContext = new DefaultHttpContext { RequestServices = this.ServiceScope.ServiceProvider, }; this.HttpContextAccessor.HttpContext = httpContext;

Now if we implement authorization/authentication on these Business Objects this approach falls over.

[rockfordlhotka]

Exactly where are you putting this code?

[skeeler88]

In IHostedService implementation

The injected services

        public HostedService(
            IServiceScopeFactory serviceScopeFactory,
            LinkGenerator linkGenerator,
            IEmailSender emailSender,
            IServer server,
            IHttpContextAccessor httpContextAccessor)

        public Task StartAsync(CancellationToken cancellationToken)
        {
            var httpContext = new DefaultHttpContext
            {
                RequestServices = this.ServiceScope.ServiceProvider,
            };
            this.HttpContextAccessor.HttpContext = httpContext;
            var command = DataPortal.Create<CommandTest>();
            return Task.CompletedTask;
        }

[dazinator]

@rockfordlhotka

When I used CSLA a long time ago, before .net core support was supported, I manged to get this all working like so:

First, create an application context manager that doesn't rely on HttpContext:

 /// <summary>
    /// Default context manager for the user property
    /// and local/client/global context dictionaries.
    /// </summary>
    public class ApplicationContextManager : IContextManager
    {

        private AsyncLocal<IPrincipal> _user = new AsyncLocal<IPrincipal>() { Value = new global::Csla.Security.UnauthenticatedPrincipal() };
        private static ContextDictionary _globalContext;

        private AsyncLocal<ContextDictionary> _localContext = new AsyncLocal<ContextDictionary>();
        private AsyncLocal<ContextDictionary> _clientContext = new AsyncLocal<ContextDictionary>();

        private const string _globalContextName = "Csla.GlobalContext";

        /// <summary>
        /// Returns a value indicating whether the context is valid.
        /// </summary>
        public bool IsValid
        {
            get { return true; }
        }

        /// <summary>
        /// Gets the current user principal.
        /// </summary>
        /// <returns>The current user principal</returns>
        public virtual IPrincipal GetUser()
        {
            return _user.Value;
            //   return Thread.CurrentPrincipal;

        }

        /// <summary>
        /// Sets teh current user principal.
        /// </summary>
        /// <param name="principal">User principal value</param>
        public virtual void SetUser(IPrincipal principal)
        {
            _user.Value = principal;
          //  IPrincipal current = _user.Value;
            //    Thread.CurrentPrincipal = principal;
        }

        /// <summary>
        /// Gets the local context dictionary.
        /// </summary>
        public ContextDictionary GetLocalContext()
        {
            //  LocalDataStoreSlot slot = Thread.GetNamedDataSlot(_localContextName);
            // return (ContextDictionary)Thread.GetData(slot);
            return _localContext.Value;
        }

        /// <summary>
        /// Sets the local context dictionary.
        /// </summary>
        /// <param name="localContext">Context dictionary</param>
        public void SetLocalContext(ContextDictionary localContext)
        {
            //  LocalDataStoreSlot slot = Thread.GetNamedDataSlot(_localContextName);
            // Thread.SetData(slot, localContext);
            _localContext.Value = localContext;
        }

        /// <summary>
        /// Gets the client context dictionary.
        /// </summary>
        public ContextDictionary GetClientContext()
        {
            //if (ApplicationContext.ExecutionLocation == ExecutionLocations.Client)
            //{
            //  return (ContextDictionary)AppDomain.CurrentDomain.GetData(_clientContextName);
            //}
            //else
            //{
            //  LocalDataStoreSlot slot = Thread.GetNamedDataSlot(_clientContextName);
            //  return (ContextDictionary)Thread.GetData(slot);
            //}
            return _clientContext.Value;

        }

        /// <summary>
        /// Sets the client context dictionary.
        /// </summary>
        /// <param name="clientContext">Context dictionary</param>
        public void SetClientContext(ContextDictionary clientContext)
        {

            //if (ApplicationContext.ExecutionLocation == ExecutionLocations.Client)
            //{
            //  AppDomain.CurrentDomain.SetData(_clientContextName, clientContext);
            //}
            //else
            //{
            //  LocalDataStoreSlot slot = Thread.GetNamedDataSlot(_clientContextName);
            //  Thread.SetData(slot, clientContext);
            //}
            _clientContext.Value = clientContext;
        }

        /// <summary>
        /// Gets the global context dictionary.
        /// </summary>
        public ContextDictionary GetGlobalContext()
        {
            return _globalContext;
            //LocalDataStoreSlot slot = Thread.GetNamedDataSlot(_globalContextName);
            //return (ContextDictionary)Thread.GetData(slot);
        }

        /// <summary>
        /// Sets the global context dictionary.
        /// </summary>
        /// <param name="globalContext">Context dictionary</param>
        public void SetGlobalContext(ContextDictionary globalContext)
        {

            _globalContext = globalContext;
            //LocalDataStoreSlot slot = Thread.GetNamedDataSlot(_globalContextName);
            //Thread.SetData(slot, globalContext);

        }
    }

Next, also implement one that does use HttpContext - note how this one returns false for IsValid when there is no HttpContext available so CSLA know's not to use it. (UPDATE: Pasted wrong class below, just pasted correct one!)

 /// <summary>
    /// Application context manager that uses HttpContextAccessor whenr esolving HttpContext
    /// to store context values.
    /// </summary>
    public class HttpContextAccessorContextMananger : IContextManager
    {

        private const string _localContextName = "Csla.LocalContext";
        private const string _clientContextName = "Csla.ClientContext";
        private const string _globalContextName = "Csla.GlobalContext";

        private readonly IServiceProvider _serviceProvider;

        public HttpContextAccessorContextMananger(IServiceProvider serviceProvider)
        {
            _serviceProvider = serviceProvider;
        }


        protected virtual HttpContext GetHttpContext()
        {
            var httpContextAccessor = (IHttpContextAccessor)_serviceProvider.GetService(typeof(IHttpContextAccessor));
            if (httpContextAccessor != null)
            {
                if (httpContextAccessor.HttpContext == null)
                {
                    //   Debugger.Break();
                }
                return httpContextAccessor.HttpContext;
            }

            // Debugger.Break();
            return null;
        }


        /// <summary>
        /// Gets a value indicating whether this
        /// context manager is valid for use in
        /// the current environment.
        /// </summary>
        public bool IsValid
        {
            get
            {
                var httpContext = GetHttpContext();
                return httpContext != null;
            }
        }

        /// <summary>
        /// Gets the current principal.
        /// </summary>
        public System.Security.Principal.IPrincipal GetUser()
        {
            return GetHttpContext()?.User;
        }

        /// <summary>
        /// Sets the current principal.
        /// </summary>
        /// <param name="principal">Principal object.</param>
        public void SetUser(System.Security.Principal.IPrincipal principal)
        {
            var context = GetHttpContext();
            if (context != null)
            {
                context.User = (ClaimsPrincipal)principal;
            }
            else
            {
                //  Debugger.Break();
            }

        }

        /// <summary>
        /// Gets the local context.
        /// </summary>
        public ContextDictionary GetLocalContext()
        {
            return (ContextDictionary)GetHttpContext()?.Items[_localContextName];
        }

        /// <summary>
        /// Sets the local context.
        /// </summary>
        /// <param name="localContext">Local context.</param>
        public void SetLocalContext(ContextDictionary localContext)
        {
            var context = GetHttpContext();
            if (context != null)
            {
                context.Items[_localContextName] = localContext;
            }
            else
            {
                //  Debugger.Break();
            }
        }

        /// <summary>
        /// Gets the client context.
        /// </summary>
        public ContextDictionary GetClientContext()
        {
            return (ContextDictionary)GetHttpContext()?.Items[_clientContextName];
        }

        /// <summary>
        /// Sets the client context.
        /// </summary>
        /// <param name="clientContext">Client context.</param>
        public void SetClientContext(ContextDictionary clientContext)
        {
            var context = GetHttpContext();
            if (context != null)
            {
                context.Items[_clientContextName] = clientContext;
            }
            else
            {
                //  Debugger.Break();
            }
        }

        /// <summary>
        /// Gets the global context.
        /// </summary>
        public ContextDictionary GetGlobalContext()
        {
            return (ContextDictionary)GetHttpContext()?.Items[_globalContextName];
        }

        /// <summary>
        /// Sets the global context.
        /// </summary>
        /// <param name="globalContext">Global context.</param>
        public void SetGlobalContext(ContextDictionary globalContext)
        {
            var context = GetHttpContext();
            if (context != null)
            {
                context.Items[_globalContextName] = globalContext;
            }
            else
            {
                //  Debugger.Break();
            }
        }
    }

Then configure CSLA to use these two context managers:

  Csla.ApplicationContext.WebContextManager = options.WebContextManager ?? new HttpContextAccessorContextMananger(serviceProvider);
            Csla.ApplicationContext.ContextManager = new ApplicationContextManager();

Now, when CSLA is used without HttpContext available, it should automatically use the correct context manager and vice versa.

What about IServiceProvider?

I had CSLA obtain the current IServiceProvider using the following logic:

1. Is there an IServiceProvider set in LocalContext - use it.
2. If not, fall back to one in GlobalContext
3. (I then optionally used this service provider to proactively check for HttpContext (via IHttpContextAccessor) to see if we are running in the presence of a http request, and - if present, then "upgrade" the SP to HttpContext.RequestServices. This step is not really necessary if you are instead prepared to use middleware in your http pipeline that sets the HttpContext.RequestServices IServiceProvider into CSLA.LocalContext for the incoming request, so that CSLA can retrieve it during step 1 above).

The pattern is basically, on application startup, once the application level IServiceProvider is built , it gets stored in GlobalContext.

However specific workloads (like for an incoming request, or perhaps a background job) can create a scoped IServiceProvider and stick it in LocalContext and CSLA will then use that instead - overriding the global level one. The beauty of this is this allows things like Hangfire background jobs (not just http requests) to share the current DI scope with CSLA by setting the scoped IServiceProvider into CSLA local context at the start of the job.

  /// <summary>
    /// Anti pattern necessary to achieve DI in some places in CSLA framework  - this was written before CSLA was using IServiceProvider or had .net core support at all..
    /// </summary>
    public static class ServiceProviderCslaExtensions
    {
      
        public static void SetAsCslaGlobalContextServiceProvider(this IServiceProvider serviceProvider)
        {
            global::Csla.ApplicationContext.GlobalContext.SetServiceProvider(serviceProvider);
        }

        public static void SetAsCslaLocalContextServiceProvider(this IServiceProvider serviceProvider)
        {
            global::Csla.ApplicationContext.LocalContext.SetServiceProvider(serviceProvider);
        }

        /// <summary>
        /// Returns the local csla service provider if available, but falls back to the global csla service provider if not. Also checks for an active HttpRequest
        /// and uses HttpContext.RequestServices if found.
        /// </summary>
        /// <returns></returns>
        public static IServiceProvider GetServiceProviderFromCslaContext()
        {
            // check local first, then fallback to global.
            IServiceProvider sp = null;
            sp = global::Csla.ApplicationContext.LocalContext.GetServiceProvider();
            if (sp == null)
            {
                sp = global::Csla.ApplicationContext.GlobalContext.GetServiceProvider();
            }

            // double check if an http request scoped service provider is available.
// note: this check shouldn't be necessary if the middleware is in play..
            var httpContextAccessor = (IHttpContextAccessor)sp.GetService(typeof(IHttpContextAccessor));
            if (httpContextAccessor != null)
            {
                if (httpContextAccessor.HttpContext != null && httpContextAccessor.HttpContext.RequestServices != null)
                {
                    sp = httpContextAccessor.HttpContext.RequestServices;
                }
            }

        
            return sp;
        }      

        public static TService Locate<TService>()
        {
            var sp = GetServiceProviderFromCslaContext();           
            var implementation = sp.GetService<TService>();
            return implementation;

        }
    }

and here was the middleware I used:

  appBuilder.Use(async (context, next) =>
            {
                // On every incoming request, set request services into CSLA local-context.
                context.RequestServices.SetAsCslaLocalContextServiceProvider();
                await next.Invoke();
                // Do logging or other work that doesn't write to the Response.
            });

[dazinator]

Thats odd about global context. Its possible I was "getting away with it" when placing the application level IServiceProvider in global context because we weren't using a remote server. Or could there be Csla code that doesn't serialise non serializable objects? Either way if its wrong and I was fortunate I wouldn't condone putting it in global context. However the basic mechanism / principal remains the same - put it somewhere globally accessible to csla, but that doesn't flow to the remote server - and on the remote server itself, its somewhere globally accessible that doesn't flow to a client.

[rockfordlhotka]

In terms of the DI provider (ServiceProvider), when you call AddCsla during app startup CSLA will capture the IServiceCollection instance.

That is a fallback. In most cases the UseCsla method will capture the ServiceProvider already created by .NET. For example, in a web setting.

Only if the provider somehow wasn't captured in a UseCsla method will one be created using the IServiceCollection. That should only happen if you are self-hosting (console app or something) and didn't otherwise create a provider.

In any case, the top-level provider is stored in a static, because this instance is generally a per-process thing, not per-thread or per-request.

In all cases, where CSLA needs to resolve anything via DI, it uses a scoped provider for that purpose. If a scoped provider doesn't exist one is created and maintained in LocalContext, because this is per-request or per-thread.

It is important to understand that you can set the IServicesScope on the current context via the CSLA fluent config model. So if one already exists you can have CSLA use that, otherwise it'll create its own.

[rockfordlhotka]

Regarding GlobalContext - you just got lucky because you didn't have a remote server 😄

[rockfordlhotka]

Also of note regarding DI, is that in CSLA 6 developers will be required to initialize DI to use CSLA.

This will resolve a host of issues, because CSLA shouldn't need to manage any service provider references itself. The goal is that CSLA can just use DI, knowing that there's already a service provider available.

The cascade effect of this change will be, I suspect, quite large. Probably comparable to where we introduced the use of generics back in 2005.

[dazinator]

The goal is that CSLA can just use DI, knowing that there's already a service provider available.

If this mandates that the application manages the IServiceProvider and DI scopes and can just tell csla at any given time which IServiceProvider it should be using (i.e will flow but is isolated like local context does / is) then I think this is the change im waiting for! If its something different I'll still be excited to check it out ;-)

[dazinator]

Do you have any idea how to access the existing provider instance?

Yes, but I should say that aspnet core creates this scope specifically for a request - but other user / application code is perfectly entitled to create separate DI scopes and csla won't know how to access them at all because there will be no singular way for csla to know about which scope it should be using unless something tells it. For a request, middleware can access HttpContext.RequestServices (and outside a middleware you can check IHttpContextAccessor to get current HttpContext and if there is one get RequestServices) and gives you the IServiceProvider associated with the IServiceScope that asp.net core has created for the reuqest and will dispose at the end of the request. For a background job, the user might create their own DI scope and have their own IServiceProvider which csla can't automatically know about. Csla can know about the application level (root / default scope if you like) because it gets access to this on startup, but csla can't assume that just because there is an httpcontext in play that this is the scope it should be using (this is a fairly safe assumption most of the time but not technically correct) because user code might create a new DI scope even during a reuqest, and they might want csla to run within their more granular scope than the request. Likewise in a background job a user might create several distinct scopes and run csla within each of those, or just one. If a scope is in play, a new / different IServiceProvider is in play, and csla needs to be told what that is, and this has to be local to the caller (I.e propagated similar to local context)

[rockfordlhotka]

See my concurrent reply to the previous thread - if you do create your own scope, then you obviously have that scope and can provide it to CSLA for its use.

[dazinator]

It is important to understand that you can set the IServicesScope on the current context via the CSLA fluent config model. So if one already exists you can have CSLA use that, otherwise it'll create its own.

Thanks I just read the concurrent reply!

This is pretty much almost there then! The slight issue I think is remaining is that:

1. For a request, we can't access the requests IServiceScope only the IServiceProvider associated with that scope so we can't prevent csla from creating a new scope when we have one in play already.
2. Imho csla shouldn't need an IServiceScope handed to it - this is owned and disposed by the application, csla just needs to operate within a given scope by using the same IServiceProvider as that scope - so csla really just needs to allow the caller to set an IServiceProvider not an IServiceScope as far as I can tell. This solves problem 1 above as csla can be given the IServiceProvider from HttpContext.RequestServices, but it also solves other scenarios in the same way, i.e in a background job or another location (unit test?) where a user creates a new DI scope, they can hand csla the scopes IServiceProvider.

In all cases, where CSLA needs to resolve anything via DI, it uses a scoped provider for that purpose. If a scoped provider doesn't exist one is created

Could you clarify why Csla needs to create a new DI scope? Does it dispose of this scope? If it creates a scope that is never disposed then this basically suffers from some issues. For example IDisposable transients will continue to build up until out of memory exception occurs (di scopes track IDisposable transients and they don't get released until the scope is disposed)

[rockfordlhotka]

For a request, we can't access the requests IServiceScope only the IServiceProvider associated with that scope so we can't prevent csla from creating a new scope when we have one in play already.

If, at the top of the request (like in a data portal interceptor) you set the IServiceScope manually, then CSLA will use your scope and won't create its own.

Imho csla shouldn't need an IServiceScope handed to it

Oh totally!! Unfortunately right now there's no way around this, because DI is a "turtles all the way down" sort of thing. Either you use DI from top to bottom, or you need to hack it into the middle.

Having CSLA require a DI container, and rely on DI to create the top level object in a call chain (for example, the data portal server instance) is a major breaking change to all existing code. And that's what I propose for CSLA 6.

I didn't want to take such a major step right now, when so many people are just moving (or thinking about moving) from .NET Framework into this brave new world of .NET Core and .NET 5. That's a big thing by itself, without having a lot of serious changes in terms of using CSLA.

Honestly, I don't even know the full extent of the breaking changes that'll be incurred by the DI change in CSLA 6 - but I'm sure there'll be a lot of them.

[rockfordlhotka]

by giving csla access to an IServiceProvider

See, this should never happen! If DI is used from top to bottom, then no user code (including CSLA code) should ever directly interact with the service provider. That's why the DI framework makes it really hard to get access to the service provider - because none of us should be interacting with it directly.

[rockfordlhotka]

That said, (you can probably tell I'm running through all this in my mind), CSLA will need access to the service provider because we are implementing method-level injection and that's not supported by DI normally.

In other words, we MUST HAVE THE PROVIDER so we can resolve types expressed via Inject parameters on the data portal operation methods.

So I guess in the end, some of today's implementation won't be all that different. At the same time, a number of other things become possible if we can count on DI being available instead of using the provider pattern throughout CSLA like today.

[dazinator]

In other words, we MUST HAVE THE PROVIDER so we can resolve types expressed via Inject parameters on the data portal operation methods

Yeah!

That's why the DI framework makes it really hard to get access to the service provider -

Its not actually hard to access the service provider its really easy - Do you register any csla services as scoped or transient? You can have IServiceProvider injected into any of those just add it as a constructor param. Perhaps you could do this - if for example data portal was scoped or transient, it could have IServiceProvider injected which should be current scope (same scope as the service itself has been created in). All it needs to do is use that for resolving inject dependencies and bobs your uncle? However with this scheme you'd have to ensure DataPortal was being created in the correct scope - in other words, resolved using the correct IServiceProvider and this would come back to what has been discussed above- caller having a way to set IServiceProvider for csla to use in local context.

[rockfordlhotka]

Today there's no guarantee that there's a CSLA type created via DI. In CSLA 6 there will be a guarantee though, so I think you are correct about being able to get the current service provider injected. At least I hope so 🤞