Consider generalized mechanism for registering services in config file


Scenario: Someone creates an EF pluralization service for some language. It should be possible to ship this in a NuGet package and have that NuGet package automatically register the service when it is installed. This either requires that the service is registered in DbConfiguration, which may not be being used, or in the config file. But the config file only allows certain services to be registered using bespoke XML. This is good for readability and necessary for back compat, but it would also be good to have a general mechanism which allows any service to be registered. We might also look at making it easy to change DbConfiguration if it is present, especially for Windows Store scenarios.
Closed Jan 15 at 10:25 PM by Mugdhak
Verified fixed


mgirgin wrote Jan 11, 2013 at 6:33 PM

Considering for EF6

ajcvickers wrote Jun 7, 2013 at 8:41 PM

Punting to post EF6 following mini triage by email.

ajcvickers wrote Oct 21, 2013 at 4:13 PM

This has come up again while working with a partner team and it seems like the ability to register a hook in the config file could be really useful. This would then allow arbitrary registration of services through code that is then registered via this hook.

ajcvickers wrote Oct 30, 2013 at 8:06 PM

Fixed in 62bfd2d5d2c6

The Underground in November 1970 (765: Consider generalized mechanism for registering services in config file)

DbConfiguration has a Loaded event which is fired when the configuration has been loaded and is just about to be locked. This is very useful for third-party utilities who need to wrap or modify configuration as EF is initializing. However, it is not always easy for third-party code to find a place to run the code that will register the event. This change allows Loaded event handlers to be registered in the app.config or web.config, which is a place that third-party code can easily change, especially if installed by NuGet.

ajcvickers wrote Nov 1, 2013 at 3:39 PM

Reactivating due to design change decision.

ajcvickers wrote Nov 1, 2013 at 8:07 PM

Diego has some different ideas; leaving issue as Proposed and unassigned for now.

divega wrote Nov 5, 2013 at 7:33 PM

To summarize the new idea we have been discussing:
  • Define a new interceptor (and the corresponding interface) that is equivalent to the DbConfiguration.Loaded event
  • Create a general way of registering EF interceptors in the config file, e.g. given an entry with a type in this section of the config file, we should discover all the interceptable interfaces this type implements and register them automatically.

ajcvickers wrote Jan 2 at 7:59 PM

New design in: 50fca7486df3

Tweedledum and Tweedledee (765: Allow interceptors to be registered in config file and add interceptor for DbConfiguration.Loaded)

The general change here is to allow any interceptor to be registered in the app.config/web.config file. Also, a new DbConfigurationIntereceptor has been introduced with one method which is the equivalent of the DbConfiguration.Loaded event. When combined these two changes mean that the equivalent of a Loaded event handler can now be registered in the application's config file. Given this, the current mechanism for registered in Loaded event handlers in the config file has been removed.