App.config file in a DLL, best practice.

First of all, no assembly or assembly module really access "App.config" file literally. This name appears only as a project artifact, which is, if present, copied by one of the build steps to the output directory, to be served as a default application configuration file when the application is deployed. The name of this file is derived from the name of the main executable module of the entry assembly of the assembly; say, if you application's main (entry-point) executable module is "myTool.exe", the configuration will be in "myTool.exe.config".

Note that the whole point is the possibility to modify this file by the user, manually or during some custom installation step. Practically, when such possibility is not needed, this configuration file would be totally pointless. In this case, the developer of the application could have fixed data set, in some resources or even hard-coded. Moreover, the project does not need "App.config" to use the configuration file. The .NET runtime "doesn't know" anything about files in the project, but it applies the configuration data if properly formatted and named configuration file is found. Default properties of the data will always be applied. The point is: the whole mechanism makes sense when it relies on this runtime system behavior. If you need something else, you should better use your own custom file, the way you want. (Note that there are also setting files, but I would prefer not using them, because the persistence mechanism is not flexible enough, and, at the same time, it does not provide any features I could easier implement myself. Not the same with config files, which really should be used in many cases.)

That said, I see no sense in having configuration files in other assemblies ("DLLs"). You can use any custom persistence mechanism, unless you don't want to delegate all settings to the main assembly of the application. I would strongly recommend XML or JSON file based on data contract. This mechanism is the easiest to use, most advanced, robust and non-intrusive. You just define your data model, and the serializer stores it and later restores to exact same state. Please see: Using Data Contracts[^].

—SA