Create a WCF-to-gRPC Proxy with Visual ReCode 1.1

Visual Recode 1.1 is now available with the ability to create a WCF server proxy to bridge client traffic from a WCF implementation to your new gRPC implementation, enabling you to move your application forward without leaving older clients behind. To try out this proxy, Download Visual ReCode now!

How to update a WCF Service to .NET Core

So you want to update your WCF service to .NET Core gRPC to take advantage of the performance and features of .NET Core. That’s great, but what about all the consumers of your service who are using a SOAP or WCF NetTCP client to talk to it? The developers on those teams have their own priorities, and switching to a new RPC protocol might not be at the top of their lists right now.

In Visual ReCode 1.0, we provided a feature to generate a backward-compatible client package for .NET 4.5+ and .NET Standard 2.1, which you could distribute to your users to make it easier to transition to the new service. That works well for internal apps that are written in .NET, but what about external users of your service, or teams that are using a different programming language to build their stuff?

In Visual ReCode 1.1, you can generate a WCF Proxy service that exposes the same interface as the original WCF application, which acts as a facade to your new gRPC service. You can configure the bindings on that proxy to match the original, host it on the original service’s endpoint, and downstream consumers can continue to use that service until they have the time and resources to update their app to use gRPC natively.

Even better, you can add monitoring to the Proxy application so you can see how many people are still using the old API and may need a little encouragement or incentive to adopt gRPC.

Creating a WCF Proxy the Easy Way with ReCode

To add the Proxy to your migrated solution, just check the Generate WCF Proxy Project box on the Configure Output page of the wizard:

Or in the Design view of the migration:

The Generated WCF Proxy Project

The Proxy application is a very thin wrapper around the gRPC client, using either basicHttpBinding for simple request/reply services, or wsDualHttpBinding for duplex services. Obviously you will want to configure or tweak the bindings to match your original WCF service.

The service implementation is a straight-forward wrapper around the gRPC client. Here’s a sample:

public partial class Calculator : ICalculator, IDisposable
{
    private readonly Channel _channel;
    private readonly BasicCalculatorCore.WcfProxy.Protos.Calculator.CalculatorClient _client;

    public Calculator()
    {
        var url = ConfigurationManager.AppSettings.Get("recode:GrpcServerUrl");
        _channel = new Channel(url, ChannelCredentials.Insecure);
        _client = new BasicCalculatorCore.WcfProxy.Protos.Calculator.CalculatorClient(_channel);
    }

    public async Task<double> Add(double value1, double value2)
    {
        var request = new Protos.AddRequest
        {
            Value1 = value1,
            Value2 = value2,
        };
        var response = await _client.AddAsync(request);
        var returnValue = response.Value;
        return returnValue;
    }
}

As you develop your gRPC service further post-ReCode, it should be easy to keep the WCF Proxy up-to-date for as long as your users need it just by updating the .proto file and editing the service implementation.

A Note On TLS

The WCF Proxy uses the original 2.x gRPC NuGet packages for .NET 4.5, which work differently to the .NET Core packages. A big difference is that the older packages require both a client and server certificate to communicate over TLS. If the client doesn’t have a certificate, it will use plain HTTP to connect to the server. To cope with this, we have added a command-line argument, --http, to the generated gRPC .NET Core service which will force it to accept unencrypted connections, and used ChannelCredentials.Insecure in the WCF Proxy application.

This is so you can get up-and-running quickly, but you should generate certificates for both client and server and use mutual TLS as soon as possible. Mutual TLS means that both the client and the server can determine that the other is trusted. You can learn about setting up TLS in your new gRPC application in the gRPC for WCF Developers e-book on Microsoft’s Architecture guide web site, and about SslCredentials for the client from the gRPC API reference.