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.
Comments: 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?
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.
Comments: 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?