c# - How would I pass a Web API Request through Dependency Injection? -

c# - How would I pass a Web API Request through Dependency Injection? -

i having web api application in controller has services/repositories etc. injected through dependency injection (unity). let's assume have istuffservice needs iprincipal of current request (or wrapper around it).

the problem web api seems only reliable source of current request/user request property on instance of apicontroller. static (be httpcontext.current, callcontext.get/setdata or thread.get/setdata) not guaranteed on same thread due sync nature of web api.

how reliably ensure request-specific context passed through dependencies, , more importantly, operation retains right iprincipal way through operation?

two options:

every method needs iprincipal has argument method - reliable way, requires me have thing in every method signature inject iprincipal ctor of service, spinning new insance of object graph on every request, using dependencyoverride in unity: container.resolve(optype, new dependencyoverride(typeof(iprincipal), principal))

option 2 means method signatures clean, means need create sure dependencies using transientlifetimemanager, not singleton or per-thread one.

is there improve solution i'm not seeing?

from comments:

@michaelstum, believe httpcontext.user should flowed correctly across async/await (within same http request). not you? – noseratio 17 hours ago

@noseratio see other answers - in .net 4.0, it's bound current thread , not maintained. seems in 4.5, might fixed. said, httpcontext.current still not appropriate in web api because on self-hosted ones there no httpcontext.current.

afaik, there's no proper back upwards async/await in asp.net 4.0 anyway (you can utilize microsoft.bcl.async language support, there no asp.net runtime support, you'd have resort asyncmanager implement tap pattern).

that said, i'm 99% sure thread.currentprincipal still correctly flowed across await continuations in asp.net 4.0. that's because gets flowed part of executioncontext flow, rather synchronization context. htttcontext.current.user, i'm not sure if flow correctly in asp.net 4.0 (although in asp.net 4.5).

i've re-read question, find explicit complaint thread.currentprincipal not beingness correctly flowed. experiencing issue in existing code (if so, bug in asp.net)?

here's list of related questions, answered great insights stephen cleary:

understanding context in c# 5 async/await

why "await task.yield()" required thread.currentprincipal flow correctly?

using asp.net web api, executioncontext isn't flowing in async actions

this blog post scott hanselman related, although speaks webforms:

system.threading.thread.currentprincipal vs. system.web.httpcontext.current.user or why formsauthentication can subtle

if you're concerned self-hosting scenarios, believe thread.currentprincipal still flowed correctly there (once having been set right identity). if want flow other properties (besides those automatically flowed executioncontext), can roll out own synchronization context. alternative (not nice, imo) use custom awaiters.

finally, if face situation require thread affinity across await continuation (much in client side ui app), have such option, (again, using custom synchronization context):

how utilize non-thread-safe async/await apis , patterns asp.net web api?

c# asp.net .net asp.net-web-api async-await