Why is that?
If one takes the time to think about it, class libraries only ever execute in the context of an application – a web application, a console application, a unit test runner or some other executable.
A class library gets loaded into the memory space of the application and gets called and executed there.
It makes sense then that the executing application should be the one deciding on how to configure a class library it is using, rather than the other way around.
The .NET framework configuration subsystem subscribes to this idea – when using the System.Configuration namespace, the application configuration file will be the one queried, even if there is a configuration file matching the dll name.
I would add that configuration should be treated as a dependency – the values should be injected into any class or method that required them – read the excellent blog by Paul Hiles – Configuration Settings Are A Dependency That Should Be Injected.
A .NET configuration file is hooked up to the application’s AppDomain upon startup. Since a DLL in many cases simply gets loaded into the main application AppDomain, it is associated with its configuration file.
The same does not apply when creating a new AppDomain and loadiing an assembly into it.
Lastly, all of this applies only to the standard .NET built in configuration mechanism. Many other configuration frameworks and options are available for usage with DLLs.