Ok, this is rather simple, but from what I’ve seen… you can only use some sort of Windows Workflow to include another config into another (which I refuse to do).
Here’s the deal:
MAINAPP.EXE References an hypothetical LIBRARY.DLL.
MAINAPP.EXE has its own MAINAPP.EXE.config.
If you add ‘config values’ to LIBRARY.DLL (thereby creating an app.config in LIBRARY.DLL project), those values are not available at runtime even if you copy app.config into LIBRARY.DLL.config to the right path post-build.
The reason for the above is that even referenced libraries will read from the ‘mainapp.exe’ config.
So far ‘so good’. Now, when you add a WCF Service reference, visual studio creates or populates your app.config with the bindings/endpoints/etc.; but that’s added to the project where you added the reference’s config; hence, your Library.DLL.prj ends up with a nice app.config that doesn’t work because it never gets read, nor even copied to the output directory. Now you may think that you can right click that app.config and set ‘copy always’ to true. Forget it. That doesn’t do anything. (You can google for that one).
So, given the above weird scenario, how is a regular VS2008 developer working with a .NET 3.5 project going to manage the WCF service references he adds to his Business Layer dll? Is that developer supposed to COPY and PASTE all the whole section from the useless app.config in his DLL to the Mainapp.exe.config file each time there’s a change in the services or each time he adds/removes one ?
Yes. Copy and paste is the answer. It’s not a great answer, but it’s the answer, and it has been since day 1 in .NET 1.0 with AppSettings.