just a perspective ...

..  and attach a distinct and  meaningful name. When publishing metadata for a service that exposes two different service contracts in which each contain an operation of the same name an exception is thrown.  For example, if you have a service that exposes a service contract called ICarService that has an operation Get(Car c) and the same service exposes a service contract called IBookService that has an operation Get(Book b) , an exception is thrown or an error message is displayed when generating the service's metadata.  To remedy this issue you may want to consider one of the following approach: Rename one of the operations. I'd suggest give them some meaningful name, any way (such as GetCar(Car car) and GetBook(Book book) ) Set the operation Name to a different name Set one of the operations' Namespaces to a different namespace using the Namespace property Reference :  Metadata Architecture Overview

Let me share with the community with what I've learnt and successfully implemented a generalised data response (data packet) exchanged between the consumer and the provider, in context to WCF services ..  The idea behind this concept is pretty simple! Instead of expecting a specific data type returned from the server call on its own, package that as part of a container that can facilitate not only the actual data expected by the consumer for a call to any service from the provider but additionally figure out if there were any validation/error that may have happened during that service call - all in one go!  The following is a simple implementation within the context of using ASP.Net MVC on the front-end and Entity Framework as a ORM tool (data layer) .. Step 1: PayLoad.cs (where the generic payload implementation lives)     [DataContract(Name = "PayLoadListUsing={0}")]     public class PayLoadList<TEntity>     where TEntity : clas...

Quite often during the WCF implementation for services layer, we find a need to interrogate the messages inbound as well as outbound at Server (Services layer) and sometimes the same applies for the Client applications too. At a small (and I mean extremely small) data transaction shop, we realized a need to inspect SOAP XML messages inbound to our Services layer and the first thought was to leverage Fiddler . The tool Fiddler does do a good job but for some reason we could never get its reverese proxy  work with our Secured Services layer (using https). Fiddler does wonderful job when running on the client machine to trace Request and Response SOAP XMLs but then by integrating SOAPExtensionAttribute I'd rather do the same from within my own application. The need for us was to trap messages before it hits the Services layer! Anyway, so the need for inspecting messages at a WCF Services layer led me to explore the WCF extensibility model and there we have it.. WCF has a concept...