Multiple WCF services referencing the same data contracts

Question

I am building a set of WCF services that share common data contracts (or entities if you prefer). These are simple data transfer objects that are decorated with DataContract

Answer 1

It depends on what tools they are using on the client side. For instance, with Axis2 for Java the wsdl2java tool can share types by using the -u switch.

how can I share proxy objects across multiple Axis2 web service clients?

Answer 2

From my understanding and working with WCF, either one of the data contract used by the client app would not matter as long as the fully qualified name is the same and has the same data members. Internally it just create the object dynamically and reassign those data member property using the public setter.

A better approach I think is to refactor your data contract so that you will put all the common across more than one service into one assembly and refer to them hence you will not have this ambiguious or conflict issues regardless how many services are used by the client app.

Answer 3

I happen to have multiple services that share objects on my end. I am not certain why you are having this problem. In my case, I am able to access the objects in this way. . . .

SERVICE1 client = new SERVICE1()

client.CommonLibrary.Address. . .

SERVICE2 client2 = new SERVICE2()

client2.CommonLibrary.Address . . . .

Answer 4

Nice article that describes how to solve this issue. Sharing DataContracts between WCF Services

Answer 5

I also tend to keep all my Data Contracts in one assembly which is referenced by multiple services and numerous client apps, which works great but I've never tried consuming the service outside of .NET.

It might be helpful to know what technology they are using to consume the service other than .NET? What is throwing the ambigious reference message?

Answer 6

We generate our service proxies not through the Visual Studio assistant but by custom batch files calling slsvcutil.exe (as we use Silverlight). There you can specify a namespace mapping using the /n parameter like this:

"C:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\tools\slsvcutil.exe "^
 http://ServiceUrl/MyService.svc^
 **/n:http://youruri.org/CustomerService/DataContracts,CLR.Namespace.CustomerService^**
 /n:*,CLR.Namepsace.MyService^
 /r:"%ProgramFilesFolder%\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll"^
 /ct:System.Collections.ObjectModel.ObservableCollection`1^
 /edb^

So all data contracts having the namespace http://youruri.org/CustomerService/DataContracts are generated to the clr namespace CLR.Namespace.CustomerService in the proxy file and so on. Given you have generated this proxy in advance in the same proxy assembly, you can cut this whole namespace out of your second file and everything works fine - we wrote a small tool for the last step. All other contract namespaces will be generated to the CLR.Namepsace.MyService namspace (see the asterisk meaning catch all)

The process is some hazzle to set up because you have to hand craft the batch files, but once this is done it works well.