The Windows Communication Foundation (WCF) is a communication platform for the creation of distributed applications developed by Microsoft for the .NET Framework. It was introduced with the .NET Framework 3.0 in 2006, replacing .NET Remoting. With WCF, the various aspects of distributed communications are logically separated, and different communication technologies are combined into a standardized programming interface. This makes it possible to focus on the business logic without having to deal with the connection of the different communication technologies.

The structure of WCF

The following communication technologies were unified with the release of WCF.

The structure of a WCF application is based on three questions (where, how, what).

The first question, “Where”, describes the address at which the application can be found in order to communicate with it, e. g.:

• http://localhost:81/DataInputService
• net.tcp://localhost:82/TcpDataInputService
• net.pipe://localhost/PipeDataInputService
• net.msmq://localhost/MsMqDataInputService

The second question, “How”, describes which protocols and which encoding, the so-called bindings, are to be used for the communication. They are defined in the *.config of the application, allowing them to be modified at any time without the need to recreate the application. WCF supports nine different bindings:

• Basic Binding (BasicHttpBinding)
• TCP Binding (NetTcpBinding)
• Peer Network Binding (NetPeerTcpBinding)
• IPC Binding (NetNamedPipeBinding)
• Web Service Binding (WSHttpBinding)
• Federated WS Binding (WSFederationHttpBinding)
• Duplex WS Binding (WSDualHttpBinding)
• MSMQ Binding (NetMsmqBinding)
• MSMQ Integration Binding (MsmqIntegrationBinding)  

The last question, “What”, uses various contracts to define the endpoints and data types to be provided. The endpoints are defined by ServiceContracts, and the data types by DataContracts.

Example of a WCF ServiceContract and DataContract:

[ServiceContract]
public interface IDataInputService
{
    [OperationContract]
    int CreateUser(User user);
 
    [OperationContract]
    int Login(User user);
 
    [OperationContract]
    List<Time> GetTimes(int userId);
 
    [OperationContract]
    void AddTime(Time time, int userId);
 
    [OperationContract]
    List<string> Projects();
}
 
[DataContract]
public class User
{
    [DataMember]
    public string Name { get; set; }
 
    [DataMember]
    public string Passwort { get; set; }
}
 
[DataContract]
public class Time
{
    [DataMember]
    public DateTime Start { get; set; }
 
    [DataMember]
    public DateTime End { get; set; }
 
    [DataMember]
    public string Project { get; set; }
 
    [DataMember]
    public int uId { get; set; }
 
    [DataMember]
    public int Id { get; set; }
}

WCF is very popular because of its flexibility achieved with the separation and its versatility, which is why the platform is readily used in numerous projects.

Why is a migration necessary?

When .NET Core was first announced in 2016, WCF was already no longer included. WCF is not part of the subsequent .NET Core releases, including the most recent .NET 5.0.

For Microsoft, the “W” in WCF, which stands for Windows, would probably be the greatest issue in porting. In order to do justice to .NET Core, a cross-platform solution would have to be found for this purpose. One of the problems in this context are the Windows-specific operating system libraries currently used, e.g. for Socket Layers or cryptography.

Even though the developer community is asking for the integration of WCF in .NET Core, it is unlikely that Microsoft will provide this in the foreseeable future.

The future with gRPC and Web API

To make an existing project sustainable, or generally use the advantages of .NET Core, porting to .NET Core should be the aim. This is particularly useful for projects that are being actively and continuously developed. If WCF is used in a project, this poses an additional challenge in porting. First, an alternative needs to be found, and then a preparatory transition of WCF is required. Microsoft generally recommends two alternatives, gRPC and Web API, to replace WCF.

We are going to present these two alternatives in a series of blog posts, discussing the respective particularities and challenges of the migration. More articles will follow shortly.