1

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

Improve this question
1

2 Answers 2

Reset to default
3

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.

Improve this answer
1

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.

Improve this answer
4
  • I think this is basically Option 3, where the library defines how its configuration looks like, and the main application loads it and passes it to the library. The library would then be completely independent, but its more complicated to exchange the library implementiation in the main app Commented Aug 21, 2023 at 6:40
  • 1
    @NoConnection: if the library is abstracted by interfaces etc than it shouldn't be a big problem to exchange it. Otherwise some work will always be required. Alternatively you may also try to abstract the library in the main app so you later only adjust the abstraction to deal with a new library. Commented Aug 21, 2023 at 6:46
  • 1
    I'm using interfaces for all implementation classes. However there are still implementation-specific settings such as a webserveraddress, that I don't know how to abstract. My question is how to store/handle these library-implementation-specific settings in such a ways that the main application is not aware of them Commented Aug 21, 2023 at 7:34
  • 1
    If you can provide enough working code then with the last question Code Review might be able to help with more concrete solutions. Commented Aug 21, 2023 at 7:44

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.