How to name several versions of ServiceContracts in the same WCF service?

When you need to make changes to a ServiceContract, it is best to keep the old one and create a new one, and use some version identifier in the namespace.

If I understood this correctly, I would have to do the following:

[ServiceContract(Namespace = "http://foo.com/2010/01/14")] public interface IVersionedService { [OperationContract] string WriteGreeting(Person person); } [ServiceContract(Name = "IVersionedService", Namespace = "http://foo.com/2010/02/21")] public interface IVersionedService2 { [OperationContract(Name = "WriteGreeting")] Greeting WriteGreeting2(Person2 person); } 

With this, I can create a service that supports both versions. This really works, and it looks great when testing with soapUI.

However, when I create a client in Visual Studio using Add Service Link, VS ignores the namespaces and just sees two interfaces with the same name. To differentiate them, VS adds "1" to the name of one of them. I end up with a proxy called

 ServiceReference.VersionedServiceClient 

and

 ServiceReference.VersionedService1Client 

Now it’s not easy for anyone to see which new version.

Should I give the interfaces different names? for instance

 IVersionedService1 IVersionedService2 

or

 IVersionedService/2010/01/14 IVersionedService/2010/02/21 

Doesn't that violate the purpose of the namespace?

Should I put them in different service classes and get a unique URL for each version?

+4
source share
1 answer

As a rule, you will not have an implementation of a service that simultaneously implements both the old and the new interface. Therefore, if a new client arrives and connects to your new service, he will receive only a new interface, and everything will be in order.

If you need to be able to offer both interfaces, then yes - you need to do the “magic” to make this possible:

  • if you can, get the new interface out of the old. This works while you only add new things. The new service implementation then implements both the old-style interface and the new

     public interface IVersionedService2 : IVersionService1 { [OperationContract(Name = "WriteNewGreeting")] Greeting WriteNewGreeting(Person2 person); } 

    Thus, your service implementation will have both the WriteGreeting method and the WriteNewGreeting method - they can connect and use them to new clients, and old clients will still see their IVersionService1 interface and the "old" namespace, and thus be able to continue service call

  • if you cannot get a new service from the old, create a completely new service and expose it to a new endpoint, for example. new address or port. Thus, existing customers can continue to call an existing and well-known service, while new ones can be directed to a separate service at a separate endpoint, and for them everything should be fine.

+4
source

Source: https://habr.com/ru/post/1305238/


All Articles