Where to put DLL specific settings?

Question

I'm not sure how to manage configuration settings in a C#/.NET environment. For simplicity lets say I have 3 assemblies: My MainApplication is the project being started and containing the business logic. It references a separate Configuration library, which reads numerous configuration values from a config.xml file that are needed in the MainApplication. Now I have another Library DataProviderWeb, which contains logic to retrieve some data from a webservice and that is loaded by the MainApplication dynamically. Later there should be another DataProvider library that retrieves the data differently. The DataProviderWeb needs some of the config values from the MainApplication and also some specific values (e.g. Webservice address etc.).

Now where is the best place to store the configuration values for the DataProvider in order to make it reusable and achieve low coupling between assemblies?.

I have elaborated multiple possibilities which all have their own drawbacks:

Option 1: All settings are stored in the global config.xml file. DataProviderWeb references Configuration, which reads all settings.

• Then DataProviderWeb is dependent on the Configuration library, which is speific to MainApplication. Therefore I can't really reuse DataProviderWeb in any other Application -> Bad
• Configuration has to be aware of implementation specific settings of the DataProvider -> Bad

Option 2: DataProviderWeb has its own config file containing all needed settings.

• Then the settings needed by both the DataProvider and the MainApplication are stored redundant in two different places and I need to make sure they always mach -> Bad
• DataProviderWeb would be completely standalone and reusable -> Good

Option 3: All settings are stored in the global config.xml file. The structure of the DataProviderWeb specific settings are defined in a class in the DataProviderWeb dll.

• Configuration needs to reference DataProviderWeb to know the structure of the configuration, therefore it and the MainApplication are dependent on the DataProviderWeb. Also DataProviderWeb isn't easily exchangeable for any other library -> Bad
• General configuration settings must be defined both in DataProviderWeb and Configuration so they can be used by both assemblies
• DataProviderWeb would be completely standalone and reusable -> Good

Option 4: I'm doing this all wrong and should use a completely different approach

Answer 1

Why not have both?

• a global config.xml file, where both libs look first for their settings

• a DataProviderWeb.config.xml file, where DataProviderWeb looks for every expected property it cannot find in the global config.xml (which should include the case where the config.xml isn't available).

That way, you can use and reuse DataProviderWeb in a different context without the global config.xml, by putting all required properties into DataProviderWeb.config.xml. Still you don't have to maintain any settings redundantly when using DataProviderWeb in conjunction with the global config file.

As a variant of this approach, DataProviderWeb can provide an initialization function where the caller is free to pass paths to one or two configuration files, in a certain order, and DataProviderWeb evaluates whatever it gets, in that order.

Answer 2

Option 2 applies because when you create a library then it should be independent, without anything being shared with other apps. That's the whole point of having a library.

Option 4 applies too. When the library needs some common settings with the main application then the library's APIs should be designed in such a way that its user, in this case the main app, passes the required values via parameters. A library should be dependent on its user specific values and not duplicate them in its own configuration.