If app.config for a DLL should be in the “main config”… what do we do with WCF References in DLLs?

Question

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 ?

Answer 1

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.

Answer 2

You can have a library project include custom config files and those files can be copied to the executable location of another application (it's a little sticky, but not too big a deal). You just have to use OpenMappedExeConfiguration to get to any information in those files. You'd then have to do some custom coding when you instantiate your WCF proxies (instantiate a Binding and pass that to the proxy). I'm late to the party here, but I can provide more details if you're interested.

Answer 3

No you're right.

But surely your WCF services are not in the business layer project, but instead in a separate project which acts as a facade into the business layer. Your business layer is then just another assembly as it should be and doesn't care how it's accessed, the WCF project does that for it.

Or of course you write custom service hosts and put the minimal amount of information in the config file (host name, certificate thumbprint) and do the rest in code.