I’ve upgraded an application from SS v4.0.15 to v4.0.30 and after fixing some small issues I’ve found that IIS fails to start with the following message appearing on the IIS log:
Type ‘Funq.ServiceEntry2' in assembly 'ServiceStack, Version=4.0.30.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable.<br><br>(full error at the bottom of the post).<br><br>I've managed to isolate this to resolving an interface scoped to request via HostContext.TryResolve while the application is starting. It used to work.<br><br>I've tried to isolate it into a test case, but so far haven't had much success, and so wanted to check if anyone else has seen this issue, or has any clue as to why it stopped working.<br><br>Thanks,<br>Bruno<br><br>Full error:<br><br>An error occurred while trying to start an integrated application instance.<br><br>Exception: System.Runtime.Serialization.SerializationException<br><br>Message: Type 'Funq.ServiceEntry2’ in assembly ‘ServiceStack, Version=4.0.30.0, Culture=neutral, PublicKeyToken=null’ is not marked as serializable.
StackTrace: at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel)
at System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironment(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters)
at System.Web.Hosting.ApplicationManager.CreateAppDomainWithHostingEnvironmentAndReportErrors(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters)
at System.Web.Hosting.ApplicationManager.GetAppDomainWithHostingEnvironment(String appId, IApplicationHost appHost, HostingEnvironmentParameters hostingParameters)
at System.Web.Hosting.ApplicationManager.CreateObjectInternal(String appId, Type type, IApplicationHost appHost, Boolean failIfExists, HostingEnvironmentParameters hostingParameters)
at System.Web.Hosting.ProcessHost.StartApplication(String appId, String appPath, Object& runtimeInterface)
It’s hard to provide any help without seeing any of the code that’s causing it. It’s likely due to the use of RequestScope use of CallContext.LogicalGetData() to store Request-Scoped dependencies.
If you try resolve registered deps outside the context of a Request (i.e. on StartUp) then it could transparently try to serialize the dependencies. So avoid resolving request-scoped deps on StartUp if you are.
Otherwise if you’re not using async ServiceStack services than you can set RequestContext.UseThreadStatic = true; to avoid using CallContext.
Bruno Lopes:
Yeah, I understand that this is not the best error report, but it confirms my thought and gives me some more info that should help in further tracking it down.
Is there a way to “simulate” the request context for dep resolution outside of a request? I ask because we’ll most likely need to also do resolution in background tasks (for which we can create a child container per “task”) and if there’s such a way perhaps we can use the same pattern in startup.
Thanks
Not 100% sure what you’re after, if it’s a RequestScoped dependency it will automatically look into RequestContext Items, i.e: https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/Funq/ServiceEntry.Generic.cs#L30
2 ways you can change where it saves Req Deps is with RequestContext.UseThreadStatic=true or setting up a new HttpContext.Current = new HttpContext()
Bruno Lopes:
That’s what I wanted to know, thanks. I might go with creating the new HttpContext during a job execution.