NullReferenceException from MVC AppliationContextManager #3963
-
I'm using Csla 7.0.4 on .Net Framework 4.7.2, with ASP.Net MVC 5 / WebApi. An API controller is calling some async data portal methods, but they are blowing up with a NullReferenceException from the Csla MVC ApplicationContextManager. at Csla.Web.Mvc.ApplicationContextManager.GetLocalContext()
at Csla.ApplicationContext.get_LocalContext()
at Csla.ApplicationContext.SetLogicalExecutionLocation(LogicalExecutionLocations location)
at Csla.Server.DataPortal.ClearContext(DataPortalContext context)
at Csla.Server.DataPortal.<Fetch>d__42.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Csla.Channels.Local.LocalProxy.<Fetch>d__18.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Csla.Channels.Local.LocalProxy.<Fetch>d__18.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Csla.DataPortal`1.<DoFetchAsync>d__19.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Csla.DataPortal`1.<FetchAsync>d__24.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() My configuration for Csla in the WebApi project
The controller does this:
We also away the actual call to the IDataPortal in both cases (both of the calls above call our factory classes, which have the IDataPortal injected. Any ideas? Should I be forcing Csla to use whatever the normal ApplicationContextManager is? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 20 replies
-
Are your factory classes injected into the controller then? So they are created via DI, allowing the DI container to resolve |
Beta Was this translation helpful? Give feedback.
You know, I seem to remember that ASP.NET did use synchronization contexts, so that config change probably does make sense.