WCF Service Reference generates its own contract interface, won't reuse mine

My first question so hope it is suitable:

Shared interface assembly - I have a 'shared' assembly which has an interface, let's call it IDocRepository. It's marked with [ServiceContract] and there are several [OperationContract]-marked methods.

WCF implementation assemblies - I have two WCF service projects, each referencing the shared assembly, each implementing that interface as a WCF service.

Consumer assembly - Finally, I have a 'client' project, also referencing the shared assembly, with a reference to each of the two WCF services.

However, the service references generated in the consumer assembly derive from an auto-generated version of the interface:

public partial class ExampleClient : System.ServiceModel.ClientBase<SomeNamespace.ExampleSvcRef.IDocRepository>, SomeNamespace.ExampleSvcRef.IDocRepository {

What I expected

I would have hoped that both references would instead automatically inherit the interface I defined, that the consumer/client assembly is also referencing. Kind of like the re-use of classes that it provides for parameter and return types, but for the service interface.

Why

So that I can create an instance of either service reference proxy and cast it to my interface type.

So I could modify the generated code by hand each time, but there should be better way...?

(edit: I do have 'Reuse types in referenced assemblies' and 'Re开发者_JAVA百科use types in all referenced assemblies' options selected for both service references)

"Reuse types in referenced assemblies" only allows you to reuse Data Contracts, not Service Contracts. If you want to share Service Contracts, you don't need to use "Add Service Reference" at all. You can just use ChannelFactory directly.

// Supply the binding and address in code
Binding binding = new BasicHttpBinding();
EndpointAddress address = new EndpointAddress("http://tempuri.org/address");
IServiceContract channel = ChannelFactory<IServiceContract>.CreateChannel(binding, address);

// Or read them from the config file
ChannelFactory<IServiceContract> channelFactory = new ChannelFactory<IServiceContract>();
IServiceContract channel = channelFactory.CreateChannel();

The channel object will also implement ICommunicationObject, so you can cast it if you need to call methods like Open() or Close().

Visual Studio does not support reusing you existing interface when generating the proxy classes for you. Reuse types will not reuse the contract interface as Quartermeister pointed out.

We have solved it with inheritance. Quite similar to the partial class idea above suggested by Jester Software.

This is how we solved it:

In the project of your client just create a service reference as you would have done. Then add a class that serves as the replacement for the client:

internal class MyServiceProxy : MyServiceClient, MyLogicNamespace.IMyService
{}

This class inherits from the generated MyServiceClient but states that that client does implement the original interface.

(I suggest you put them in a folder named "ServiceProxies")

If the MyServiceClient class contains any methods that do not match with the original interface then you can add them in that proxy and do the conversion in code.

After this, just use the MyServiceProxy where you would have used MyServiceClient.

When you create the service reference, there is a box you can tick to make it reuse the shared definitions. Make sure the client project is already referencing the shared assembly, add the service reference again, and check all the options carefully.

If it still doesn't work, check the binding you use. I have a vague recollection that basic HTTP binding won't support re-using of types?

There is another good option, if you want to continue to use the proxy generator for it's limited-but-somewhat-useful functionality... Use a partial class:

namespace <same namespace as generated proxy>
{
    public partial class MyClient : <namespace of "real" service contract>.IServiceContract
    {
    }
}

Ensure that the proxy is generating code the same way your Service Contract is defining it, ie, if it's using 'List', use that option in Configure Service References as well. In other words, make sure your generated Service Interface is exactly equal to your real Service Interface and the above code should work, and to update the reference you use right-click instead of writing code.