Because Services.GetService gives higher precedence to DependencyResolver than the list of default services, and because Services.Replace only affects the list of default services, it means any service type retrieved from a DI container will cause any replacement of that service via Services.Replace to be ignored.
This means all Services.Replace() calls from within the product or from 3rd party code can become non-operational when a DI container is introduced. This creates an ambiguity over which is the "right" way to replace a service. Moreover, the only public API available to replace a service is Services.Replace() -- which is what the product and 3rd party code must use.
One immediate effect of this is that Tracing will not work on any service coming from the DI container, even though Tracing believes it has replaced that service with a wrapped version.
This issue asks to make Services.Replace() and DI containers integrate better.
Possible options are:
1) Create new API on DependencyResolver called by Services.Replace() to provide a recommendation to the DI container that the code is attempting to replace a service. Let the DI container decide how to deal with that.
2) Let Services.Replace keep a "replacement list" that is given higher priority than the the DI container.
Comments: This is by design. If someone has registered a DI container, we honor that first.
This means all Services.Replace() calls from within the product or from 3rd party code can become non-operational when a DI container is introduced. This creates an ambiguity over which is the "right" way to replace a service. Moreover, the only public API available to replace a service is Services.Replace() -- which is what the product and 3rd party code must use.
One immediate effect of this is that Tracing will not work on any service coming from the DI container, even though Tracing believes it has replaced that service with a wrapped version.
This issue asks to make Services.Replace() and DI containers integrate better.
Possible options are:
1) Create new API on DependencyResolver called by Services.Replace() to provide a recommendation to the DI container that the code is attempting to replace a service. Let the DI container decide how to deal with that.
2) Let Services.Replace keep a "replacement list" that is given higher priority than the the DI container.
Comments: This is by design. If someone has registered a DI container, we honor that first.