It would be good if I could pass a type of HttpMessageHandler instead of an instance. That way, the DependencyResolver could automatically resolve the type including any of it's dependencies.
Right now, in order to supply dependencies I have to reference the container itself, or pass a delegate (which will call into the container). However, AFAICT the HttpMessageHandler types are initialized once, in application start so it looks like I will have to manually control the lifetime of the dependencies.
Since the handler is initialized once, if I pass a singleton for the dependency that means it won't get GC'ed at all. On the other hand, I can manually resolve an instance and then release it but I am not happy with this approach as it couples the handler with lifetime management of it's dependencies.
Comments: @eatdoku yes. I initially voted for this feature but now I am not sure whether it will be better to construct a brand-new instance of an HttpMessageHandler for every single request. I mean we can get access to DependencyScope inside an HttpMessageHandler. This is not a blocking issue.
Right now, in order to supply dependencies I have to reference the container itself, or pass a delegate (which will call into the container). However, AFAICT the HttpMessageHandler types are initialized once, in application start so it looks like I will have to manually control the lifetime of the dependencies.
Since the handler is initialized once, if I pass a singleton for the dependency that means it won't get GC'ed at all. On the other hand, I can manually resolve an instance and then release it but I am not happy with this approach as it couples the handler with lifetime management of it's dependencies.
Comments: @eatdoku yes. I initially voted for this feature but now I am not sure whether it will be better to construct a brand-new instance of an HttpMessageHandler for every single request. I mean we can get access to DependencyScope inside an HttpMessageHandler. This is not a blocking issue.