Apologies if this is a duplicate, but I’ve not managed to find this question being asked directly.
The general opinion here (that’s me and him across from me) is that they shouldn’t, the reason being that DLLs can be shared; therefore the idea of having application-specific information in a DLL is nonsense. If the information is not application-specific, then constants can be used.
A further question is, assuming that DLLs do not have their own config file, whether DLLs should use the configuration files of the executable that loaded the DLL, or instead be passed the relevant data as part of some kind of constructor. Our opinion here is the latter, as it makes it more testable, the downside being that it will sometimes be necessary to pass a significant amount of data to the dll.
Opinions?
There’s no reason why you can’t have the best of both worlds in terms of “simple to configure with config files” and “testable”. Have a static method which can create instances from the configuration file, but also provide a constructor for more control and testability. The static method would just grab the settings and call the constructor.
I believe it’s possible to create settings classes for DLLs just like any other project, and then you just need to put the actual text into the application’s config file instead of one for the DLL. Basically ignore the app.config generated for the library project, except to use as a template for the application’s central one.
Alternatively, use something like Spring.NET to manage this sort of thing 🙂