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: Given the message handler is passed as instance and being initialized once for the entire service. I think it is easier to have user code inject the dependency themselves first and register the instance with http configuration. This allow people to write custom message handler that has constructor but do not need dependency injection as well. The current model is more flexible.
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: Given the message handler is passed as instance and being initialized once for the entire service. I think it is easier to have user code inject the dependency themselves first and register the instance with http configuration. This allow people to write custom message handler that has constructor but do not need dependency injection as well. The current model is more flexible.