0

It is easy to generate a proxy for a service (which has a wsdl) with svcutil.exe.

With the command

call "%VS100COMNTOOLS%"\vsvars32.bat
svcutil.exe http://localhost:8754/MyService.svc?wsdl /out:MyProxy.cs /config:MyProxy.config

two files are generated, which are

MyProxy.cs
MyProxy.config

So, I have this wonderful files which can be used by all applications that want to call MyService.

But there seems to be no proper way of reusing them.

The config has always to be copied to the client-applications App.config.

So, I can have a library, but there is only the MyProxy.cs in it. The client-application still has to reference System.ServiceModel and System.Runtime.Serialisation assemblys on its own.

This is somewhat cumbersome.

Is there any way to "inject" that MyProxy.config or even better have a library that just can be referenced and used in the client-application?

Mare Infinitus
  • 8,024
  • 8
  • 64
  • 113

1 Answers1

0

You are heading to the right direction. The library with only MyProxy.cs is Client API, so you may name the project as MyServiceClientApi which assembly could be reused across other projects and solutions. The app.config generated contains only some simple settings of http binding, and you may consider the basic settings is a starting point of crafting real world settings which may need to be altered during application development, release, deployment and daily operation. So there's little value of auto-injecting the generated config settings into the app.config of other applications.

Regarding to your last question, please google "merge app.config" you will find quite a lot resources. However, likely the auto-merge/inject in this scenario won't boost your development productivity in long run.

And WCF for the Real World, Not Hello World may give you more hints.

ZZZ
  • 2,752
  • 2
  • 25
  • 37
  • The best would be a classlibrary that I reference to use the Proxy without changing the client application any more. But this does not seem to be possible. The config merge (with a config-file generated by svcutil and changed afterwards to the needs) is just an idea to reach reuseability and to have less maintenance. But I still have to inject the config in the App.config of the client-appliction, right? – Mare Infinitus Aug 20 '14 at 05:44
  • Yes, better to manually craft the config based on the generated one. This is often just a once off job, rather than repetitive job, so not worthy to automate it. The MyServiceClientApi.dll may be referenced by app1, app2 and app3 etc., and you need to compile the api only once, and lock it, until you change the service interface say for next version. And this will come in handy if you need to support more than 1 version of the Web service at the same time. – ZZZ Aug 20 '14 at 06:17
  • I hoped there is something like a config-chain, as there is a resource chain. The service is still in development, as the client applications are, so changes come in more on a daily basis that "just once". – Mare Infinitus Aug 20 '14 at 06:56
  • run svcutil.exe against the service assembly rather than a live URL might be a better option. More details please check http://www.codeproject.com/Articles/627240/WCF-for-the-Real-World-Not-Hello-World – ZZZ Aug 20 '14 at 08:36
  • Nice link, besides it gives no answer to the question. At least I do not see the advantage of using the assembly rather than a live URL. Could you please explain that? – Mare Infinitus Aug 20 '14 at 08:54
  • when using a live link, basically the service read the assembly to generate WSDL at run time, then you generate proxy classes from WSDL. So why not let svcutil.exe read the assembly directly? besides, making a .NET client api is a common practice, say Google and Amzaon provide .NET client API to .net developers so .net developers don't need to add Service Reference and generate proxy classes again. It is also good for service versioning. Also, not every WCF projects are for http applications, some could be for net tcp binding only, no WSDL needed. – ZZZ Aug 20 '14 at 10:34