This project is read-only.


We should open up the configuration.Services to allow user register their custom services


Today if one tries to add a custom service to the configuration.Services bag, it will throw exception saying that it does not support unknown services.

We should open this up so that people don't have to use configuration.Property bag to store those config wide settings. Also, because we will use DI first, custom service type will get the benefit.
Closed Jul 25, 2013 at 6:51 PM by eilonlipton
Comment from RaghuRam:

This bug was created during OData V1 time frame when we said “no core runtime changes”. OData had to add some custom extensibility points at the config level that time and our service container is not really designed for that. We had to use configuration.Properties to store these custom services and this idea seemed good at that time. We no longer have that problem now (inability to modify runtime). So, this bug is not relevant anymore. Also, opening up configuration.Services for general purpose DI would cause more confusion regarding scoping and caching as mentioned in the bug’s comments.


tugberk wrote Feb 27, 2013 at 9:03 PM

IMHO, this would create confusion. The idea (which is the current impl.) that Brad Wilson explained in the following issue makes more sense to me:

Separate service location from dependency injection

Service location will live in a new property, HttpConfiguration.Services, which is not user pluggable. This service list will be populated with the known default services present in the application, and the application developer can add and remove services from this list. These services are considered to be "global" to the configuration, and the single instance of these services is shared across all requests. Only known service types will be gettable or settable in the service locator.

HongmeiG wrote Feb 27, 2013 at 10:40 PM

Hi TugBerk,

The type of custom services people usually want to plug in through Services is per configuration scope, and not requiring dependency injection. One example could be an global setting used in the some higher level component, such as Web API OData.

Today, people are using the configuration.Property bag for that, which does not check the DI first, and behave differently from the built-in Web API services. This feels strange, and unnecessary limitation.

BTW, if you want to DI any services, including custom services, you can still register custom DependancyResolver for that, and it should be picked up correctly.

Does that make sense?

HongmeiG wrote Mar 29, 2013 at 2:12 AM

We should remove the throwing in httpconfiguration.