Service contract (interface) reuse for generated client side code

Question

We are currently working on a project that uses a shared interface between the client and server code where both of which are written in C#. Is it possible to have the generated client code from svcutil use the same .net interface as the server side code? We are able to include the actual interface (i.e. IService) in a shared library. Thank you for your help.

Answer 1

Hi smaclell,

 

Yes, you can share the service and data contract interfaces between service and client... just reference the same assembly in both (look at the svcutil /r flag). You can completely replace the classes generated by svcutil with the classes on the service, and your client should work without modification.

 

You should avoid this if practical in your case, since to maintain interoperability the service and client should only share their contracts in the form of  WSDL, and not the internals of the particular programming language (like classes and interfaces).

 

Thanks,

-Yavor

 

Answer 2

Thank you for your response. I understand that you should not share beyond the wsdl contract but we are making a slight exception of only sharing the interface to the service and the data contracts. We viewed this as acceptable because it gives us substantially more flexibility in creating tests as we can test the service as isolated or the generated proxy as identical through the interface.

I tried using svcutil /r with a contrived example and was still not able to reproduce the desired results. I created a wcf service project with some sample services and data contracts, I then generated the metadata and tried to create the client proxy code using "svcutil /r:myAssembly.dll /o:client.cs *.wdsl *.xsd" which only generates the config file and no client.cs.

What we want is for the proxy is to use the identical .NET interface as the service type and regardless of how I try to use the /r switch it does not seem to be working. Is this a similiar case of this bug, http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3314830&SiteID=1?

Thank you for all your help.

Answer 3

Could you please post the WSDL and XSDs you are referring to?

 

Alternatively you could create a "shared" project in VS wich contains your interfaces and reference it from both the service and client projects.

 

Thanks,

-Yavor

Answer 4

Here are links to the WSDL and XSDs I tried to test our scenario on.

• http://www.eng.uwaterloo.ca/~smaclell/schemas.microsoft.com.2003.10.Serialization.xsd
• http://www.eng.uwaterloo.ca/~smaclell/ServiceTest.xsd
• http://www.eng.uwaterloo.ca/~smaclell/tempuri.org.xsd
• http://www.eng.uwaterloo.ca/~smaclell/tempuri.org.wsdl

They should look mildly familiar because they are generated from the service created by default with a new Web WCF Service Application.

The plan is to share the assembly like you have mentioned but we would be forced to maintain the client proxy code as well. We are hoping we can use the provided tooling to generate the client proxy with our version of the service interface and data contracts. Thank you for your help.

Answer 5

I reproduced the behavior you talked about, and apparently you're hitting a known bug. If you use /r with an assembly containing a ServiceContract, it will not generate the proxy code for you. If you just want to share DataContract types, /r works fine.

 

I have somewhat of a workaround for you

1. Create the WCF Service Application just like before.
2. Create a new console app project in the same solution and add a Reference to the WCF service. I mean an assembly reference, not a proxy.
3. Then generate your proxy with svcutil, without using /r
4. Go in and delete ComplexType and IService1 from the proxy.
5. Add the proxy to the console app project - if the namespaces match up it should build, and you still defined your types and the service contract exactly once. 

What might be cleaner in your particular case is to go and use ChannelFactory directly, without pre-generating the proxy. You'll still need to reference your service project in the client to get access to the service contract interface class, but then you can just do ChannelFactory<IService> and work without a proxy. Check out this example:

http://msdn.microsoft.com/en-us/library/ms734681.aspx.

 

Hope this helps,

-Yavor

Answer 6

Yep thouse solutions will work just fine. I had completely forgotten about the ChannelFactory. Thank you for all your help.

 

- Scott

Answer 7

Hi, You can check out the following useful tool: NetXtremePROXY