Consume webservice from a .NET DLL - app.config problem

Question

Hi,

I'm building a DLL, let's call it mydll.dll, and in it I sometimes need to call methods from webservice, myservice. mydll.dll is built using C# and .NET 3.5.

To consume myservice from mydll I've Added A Service in Visual Studio 2008, which is more or less the same as using svcutil.exe. Doing so creates a class I can create, and adds endpoint and bindings configurations to mydll app.config.

The problem here is that mydll app.config is never loaded. Instead, what's loaded is the app.config or web.config of the program I use mydll in.

I expect mydll to evolve, which is why I've decoupled it's funcionality from the rest of my system to begin with. During that evolution it will likely add more webservice to which it'll call, ruling out manual copy-paste ways to overcome this problem.

I've looked at several possible approaches to attacking this issue:

1. Manually copy endpoints and bindings from mydell app.config to target EXE or web .config file.
   Couples the modules, not flexible
2. Include endpoints and bindings from mydll app.config in target .config, using configSource (see here). Also add coupling between modules
3. Programmatically load mydll app.config, read endpoints and bindings, and instantiate Binding and EndpointAddress.
4. Use a different tool to create local frontend for myservice

I'm not sure which way to go. Option 3 sounds promising, but as it turns out it's a lot of work and will probably introduce several bugs, so it doubtfully pays off. I'm also not familiar with any tool other than the canonical svcutil.exe.

Please either give pros and cons for the above alternative, provide tips for implementing any of them, or suggest other approaches.

Thanks,
Asaf

Answer 1

I should go from option 1 or 2 (for me this one is better). The modules are coupled in the dll, so they are already coupled. Changing a config is trivial, but making an infrastructure for reading will couple you more.

The 3 and 4 options is a lot more job.

Answer 2

I prefer option 5 - "In code configuration", yes yes yes, you lose change-without-recompile benefit, but in depends on what you need. If you know that you will never change your endpoints or will change it rarely - just do your configuration in code, you will get compile time checking as a bonus =) This and this can help.

And btw, configuration in client configs is a common case, if you have a lot of this clients this can be pain and you should think about 3 or 5 =)

Answer 3

I've compiled my open source web services framework down to a single dll as well. Though took a different approach entirely, I created generic IHttpHandler's for the JSON and XML endpoints (and generic WCF configuration for the SOAP endpoints) that can handle every request. So my configuration is a simple one-liner for all of my web services mapping the endpoint to my handler which resides with the application host .config file (i.e. ASP.NET Web.config or Console App.config) where it's meant to be.

Answer 4

You could use svcutil as a post-build event in the application that is consuming the DLL. Like this:

svcutil.exe <service_address> /config:$(TargetPath).config /mergeConfig

This will merge the necessary config into yourapp.exe.config. If you add a new service reference in the DLL you would have to add another line here, so it's not completely automatic, but still a bit simpler than manually copying the config.