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 and DataMember attributes. I am explicitly specifying the name and namespace. In trying to follow the principles of IDesign's recommendation of averaging 12 members per service contract, I am breaking my service project into multiple services.

My data contracts are in a separate assembly that I can provide to our clients if they are using .Net. They can tell their service reference to reuse types in referenced assemblies. However, if they are not using .net and they use 2 services that both use the same entity then they will, I assume, get an ambiguous reference message. I can see this in Visual Studio if I don't reference the data contract dll.

My question is, is there anything I can do in my services, or they can do in a client app to get around having to qualify which proxy the data contract came from?

Stanwin

I am having the same problem. I attempted to use the advice in the article below, but no joy. However, I am using WCF RESTful services (this might have something to do with the method below not working), so I ended up just referencing a common DLL that contained my data contracts, and and foregoing the service references all together. Since I call on my services using simple HTTP web requests, I don't actually need the service references in the project. – Frisby

Answer 1

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

Risotto

Answer 2

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?

Retentive

You can do it in .net, just don't reference your data contract dll and watch what happens. Create a test project, add 2 of your services that both use a common data contract as references and you'll get the ambiguous message. – Stanwin

Answer 3

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.

Stridulous

Answer 4

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.

Fokine

Fadrian, all of my data contracts are in one assembly. The issue is if 2 services reference the same data contract each services gets its own namespace version of it. – Stanwin

Paul, did you try explicitly specifying namespace in the DataContract attribute? and how did you create the data contract assembly? Did you try using svcutil tool and manually generate the data control with /namespace: parameter? I personally havent had that issue so I may not hit the right button, just sharing some thoughts here. – Fokine

Answer 5

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?

Elwood

Answer 6

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 . . . .

Gibrian

That works for me also. The point is that they are 2 different objects. The consuming application cannot just say CommonLibrary.Address, it has to be qualified with the service name. This is not really a problem, I was just wondering if the service references would detect the same namespace for the common data contracts and share it. – Stanwin