One common complaint about the .NET framework is that there is only one config file for the application, even if there are many assemblies (exes and dlls). This post contains advice for how the author of a DLL can keep the configuration settings for that DLL seperate.
The config file gets its name from the .EXE, not the DLLs. Therefore, if your U/I is the EXE (which it usually is), then your dlls will be getting their settings from the config file for the EXE.
It is often the case, however, that the DLL provides services that can be configured, and that you would want to configure those services differently for each application that uses the DLL.
On the other hand, if you want to provide a set of "common services" using your object layer, then you can create an XML file that the DLLs will use. So, how does the dll find it's XML file?
I've answered this question many different ways in different apps, trying things out to see what works. I've got three answers:
In all three cases, loading an XML is not as difficult as it first appears.
Take a look at the XSD.EXE tool that is delivered with the .NET SDK (a free download from Microsoft). Using the XSD tool, you can point at an XML and the tool will generate a class that the XML will deserialize into.
Using this class, and the XML deserialization methods built into the framework, you can very easily load the entire XML file into an object that contains other objects. Now, you can use that object "tree" to inspect your settings very easily.
In fact, if you change the values in the settings, it is very easy to save those changes back to the XML config file by simply using the serialization functions (something that is a bit more difficult with the config files).I hope this provides useful information.