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:

1. Put the name of the XML file into the registry during install.  The DLL looks to the registry to get the config file name.  This is useful if you are writing a DLL that needs to run from Biztalk or Sharepoint, since you cannot control either their executable or the directory in which they are installed.
   
2. Give the XML file a fixed name, hardcoded into dll itself.  Have the DLL look into the application directory (where the EXE lives) to find the XML file.
• Variation: in the app.config for the EXE, provide a seperate section for the DLL to use.  That section will contain the name of the XML Config file.  If no name is given, use the hardcoded name.  If neither is found, use basic default settings or raise an error in the constructor of your classes.
  
3. During install of your app, create a specific directory where nothing but the XML config file will live.  When it comes time to go looking for the file, take the first XML file that you find that lives in that directory.
   This is convenient when transferring your app from dev to test to production, because you can have three files: dev.cml, test.cml, and prod.cml (I renamed xml to cml on purpose). 
   When you install the app, all three are placed in the directory.  The next step in the install is to ask the person doing the install "what environment is this" and, using their response, rename the proper file to the "xml" extension.

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.