each assembly (wheter is an DLL or an EXE) has the opportunity to store its configuratios in an app.config-File.
Makes it sense ? It’s appropriate to your custom scneario, so i can’t give an generic answer.

An easy way to get the configs of your Assembly is by using System.Reflection.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Configuration;
using System.Reflection;

namespace Marc.MyLibrary
{
public class MySampleClass
{
public static string DoSomething()
{
// Preferences: Store an App-Config beside your Assembly (DLL or EXE)
// named as a regular app.config
// example:
// Marc.MyLibrary.dll
// Marc.MyLibrary.dll.config

// 1) Get the Location of your Assembly

string path = typeof(MySampleClass).Assembly.Location;

// 2) Use the path to get an Configuration-Object via ConfigurationManager
// (Info: Please set a reference to System.Configuration)

Configuration config = ConfigurationManager.OpenExeConfiguration(path);

// 3) Access via Indexer on your defined key
string myValue = config.AppSettings.Settings["MyKey"].Value;

return myValue;
}

}
}

Regards,

Marc

There are times when it’s better to be more modular, however. A per-assembly config file definitely isn’t the best solution for all configuration needs, but it’s one solution to one particular problem.

I’ll give you an example: at my last employer, we had four servers downloading images, all using the same DLL to help accomplish this. One of the settings in the DLL was where to cache the images. In this scenario, the local paths where the images were cached actually needed to be different on each server as a result of the servers’ hardware (physical drive sizes).

The application using this DLL already had a largly bloated configuration file for itself, so separating out the concerns of the particular DLL into its own config file made changing settings related to image caching easier.

The point of libraries, like you say, is to be modular and recyclable, and that’s exactly what decoupling the DLL settings from the application’s settings does. Is it always the best idea? No. Sometimes? Sure.

- [Current assembly location]/Foo.1.0.0.dll.config
- [Current assembly location]/Foo.dll.config
- [GlobalConfigDir]/Foo.1.0.0.dll.config
- [GlobalConfigDir]/Foo.dll.config

Care must be taken however, because in larger systems, there’s enough rope to hang one’s self (winding up with too many configs to track and update).

Plus, we have separate assemblies to keep separations of concerns with code. You create a DLL instead of adding the code to an application so that it can be plugged into an application. Just like keeping that DLL code separate from an application’s codebase is a good idea, so is keeping settings that only apply to that DLL, don’t you think?

JMP, one usage scenario, plug-ins.