So, you want to create an Indigo client proxy that references the same types as server does, IOW a client proxy that won’t recreate ServiceContract (let’s say it is an interface IMyServContract). Before the actual process I’ll shortly explain how you can actually automate the client proxy creation.
First you start by opening Windows SDK CMD Shell (it is handy since it has all paths to utilities set). Next you’ll type something like:
svcutil /o:proxy.cs /config:app.config http://localhost/server/service.svc
svcutil is utility that generates both code and config file out from url for you. The problem with that syntax is that it will generate code for service contract, too (remember, we don’t want to regenerate the service contract since we are referencing it from both client and server) and even worse, the same service contract interface will have different signature. To help you out there is /r:assemblypath option to svcutil that tells it not to regenerate types found in that assembly. You’ll rewrite your command like this: svcutil /o:proxy.cs /config:app.config /r:myassembly.dll http://localhost/server/service.svc
and expect that it will act properly. Unfortunately this isn’t the case. There is a well known bug in svcutil that doesn’t generate proxy.cs anymore.
So, here is my quick and not exactly well tested solution.
- Generate the proxy without /r option which will result in IMyServContract redeclaration.
- Open the proxy.cs file and use Refactor/Rename on IMyServContract to change it to something else, let’s say IMyServContractProxy.
- Then open generated config file and modify accordingly <client><endpoint contract> attribute to match renamed service contract.
And this is it. I tested on relatively simple sample and it worked. There is a drawback though – your proxy wont have original service contract implemented for the client by default (IOW it won’t implement IMyServContract). You can easily add implementation though as the code is already in place –
- just add IMyServContract implementation declaration to *Proxy class (which now implements IMyServContractProxy because of renaming).
There you go with fully functional proxy that references the same service contract type as server does.
UPDATE: There is an infinitely easier way to achieve this (note that the solution above was really a quick and dirty solution). Clemens suggested that you don’t need a proxy at all. Just create the channel and there you go – logical, since remoting works the same way. Currently I don’t have time to test it though.