Question

I have an existing .NET 3.5 based framework that is extended using custom plugins. In summary plugins implement a common interface and the core framework invokes these via reflection. The framework works perfectly and all is good, however…

I now have a requirement that requires a plugin that communicates with the WCF service. At face value this is simple, add a service reference to the plugin, call the client proxy code and off we go. However…

Due to the way that .NET configuration works the WCF service client configuration should reside within the app.config of the executing application. In this case this is my plugin invoker application. The problem with this is that it breaks the plugin “model” as the generic invoker application now has to have plugin specific configuration within it.

So the question is does anybody know of an alternative mechanism for handling the WCF service client configuration without putting it into the core invoker application configuration?

Having done a little hunting around there are mechanisms to allow a DLL to use its own config file. The issue here is that I don’t have access to the underlining code of the service proxy creation and therefore seemingly can’t redirect the config reads.

Answer 1

Answering my own question:

I seem to have found a solution to the problem here:

http://weblogs.asp.net/cibrax/archive/2007/10/19/loading-the-wcf-configuration-from-different-files-on-the-client-side.aspx

In summary this allows you to specify a custom configuration file that contains the WCF configuration as it is generated by Visual Studio – this means that the config can be maintained easily.

Having run a couple of quick tests it seems that it works as it should (with a few tweaks here and there (see the comments on the page).