Multiple WCF services referencing the same data contracts

user_137447 0
Viewed 22314

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?

reusability datacontract service wcf
6 Answers

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?

user_2793170

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

user_2726710
user_2276390

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.

user_2765560
Related