This question was triggered by another issue I was just dealing with. There is a managed library, MyAssembly.dll, targeting .NET 4.0. It has its own MyAssembly.dll.config file with some <bindingRedirect> instructions. I believe the .config file was generated by either compliler or NuGet package manager, as I did not create it manually.
The thing is, the binding instructions are ignored when the DLL gets loaded by a client app (RegAsm.exe in my case, but I also verified this with a simple console .NET app). I had to move them from the DLL's .config file into the client EXE app's .config file, to be picked up by .NET runtime and get correctly resolved.
The question: what is the purpose of a .config file for a managed library assembly (.DLL), at all? Does it anyhow participate in the process of loading of the library assembly?
There is no "purpose". The consumer of the library can copy the settings out of the .dll.config into their own .exe.config or web.config.
The .dll.config file simply gives Visual Studio someplace to store configuration for the library.
Consider that, in general, a single library can be used by multiple callers, each with a different configuration. It actually doesn't make much sense, in general, for the library to dictate the settings.