Converting the Microsoft WCF Sample App to .NET 5 with gRPC

Since the release of this article, .NET 6 has come out. We recommend most migrations target .NET 6., as .NET 5 enters the end of its support on May 8th 2022. You can read more on migrating WCF applications to .NET 6 here.

On March 11th, I was able to participate in Inedo’s webinar series on .NET 5 Migrations. This series so far has covered topics ranging from migrating NuGet packages, dealing with legacy webforms, and I got to cover some tools useful for .NET 5 migration planning. Specifically, I went over three tools you can use easily within Visual Studio:

1. The .NET Portability Analyzer: install this, right-click your solution, and get a report that approximates the percentage of components that will transfer to a specific version of .NET per assembly.

2. Try-convert: a Visual Studio terminal tool that will put your application on the .NET 5 SDK, but won’t guarantee that your application will even compile (the “try” in “try-convert” is very honest).

3. Visual ReCode: install this Visual Studio extension, and you can now automate rewriting WCF services to gRPC.

I thought the best way to show them off was to use them to assist two migrations from NET Framework to .NET 5. I used the .NET Portability Analyzer and Try-convert on a simple WPF application, and then I used Visual Recode on a simple WCF application. Both migrations were successful, and here’s a summary of what I did during the migration process.

How I Migrated the WPF Application

The WPF application I used for the webinar was a reskinned and slightly expanded version of the WPF .NET Framework tutorial application. Honestly, it would not have been hard to take this application to .NET 5 by hand.

The .NET Portability Analyzer gave this application a 100% compatibility grade for .NET 5, meaning it found no depreciated components used in the assembly.

I ran try-convert on the project, and you can essentially see all the work it needed to do in the .csproj file:

Mostly, it just changed the target framework to .NET 5 for windows, deleted some items, and generated a .csproj.old file in case I wanted to revert the changes. It took less time than I would have, as all I had to do was write a single line in a terminal instead of edit a file, but it’s a difference of 30 seconds versus 5 to 10 minutes, not an hour.

The WCF application was going to require a bit more of a lift to put it on .NET 5.

How I Migrated the WCF Application

The WCF application I used was the WCF tutorial application, a basic calculator.

To start, let’s take a look at the initial results from the .NET Portability Analyzer:

Our Client assembly has a score of 76.92%, and our service has a score of 87.88%. This application is probably not a good candite for try-convert, as we know that the failing components are due to using WCF, which is not on .NET 5.

So, I used Visual ReCode instead to generate a new .NET 5 gRPC service. I used the “Migrate a Service” function over the Guided Project Upgrade feature. This application is straightforward, and the Guided Project Upgrade feature is better used on difficult migrations.

I first opened the Visual Recode extension, chose to migrate a service, and selected the single service.

Next, I configured my migration settings. I selected .NET 5 as my target platform, chose to create a new solution in a different directory (never hurts to be cautious during a live demo), made a project name for the gRPC service, and decided to generate a client project as well.

The “Generate client project” option creates a shim around the gRPC client with the same interface as the WCF client had. This way, if someone has a desktop application using WCF to talk to the server, you can just hand them a library they can drop in and work functionally the same, but with gRPC (minus some calls that will be brought to Async).

The “Generate WCF Proxy Project” is for situations where you cannot have all your clients switch to a new gRPC library. This option creates a new WCF project in the newly generated solution, which has the same service contracts interface as your old project but maps any calls to the gRPC server. For the demo, I wanted to use a .NET 5 client instead of a WCF client, so I generated the client project and skipped the WCF Proxy project.

I clicked next and let Visual ReCode run through the migration. Afterward, I opened the newly generated solution and saw three generated projects:

1. A new class library for the gRPC service

2. The gRPC service itself, which has an output as a console application

3. A new class library for a client project, created by the “Generate Client Project”

Then I ran this new solution through the .NET Portability Analyzer to confirm it was .NET 5 compatible, and the results were good.

Finally, I added a client application to the project. I built a new .NET 5 console application and pasted a modified version of the client application found in the Visual ReCode sample project for the Basic Calculator on .NET Core 3.1. I simply changed the application to use my generated NET 5 gRPC services instead and ran it.

But I Didn’t Get the Chance to Cover One Thing

I’m happy enough to have done two successful migrations during the demo, but I really wish that I could take the time to show more of the generated code and compare it to the WCF solution.

The Visual ReCode examples on GitHub show some good samples for WCF to .NET Core 3.1 conversions, but I would have wanted to walk through the application we made live. So to make up for that, I’ll be writing soon on the specific files Visual ReCode generates for the basic calculator application and how it compares to the WCF version, and the stock gRCP starter project in Visual Studio.

Until then, you can check out the samples on GitHub, or try out Visual ReCode on your own applications! The trial will not convert your entire project (it will convert 1 in 3 methods arbitrarily), but it will supply a sample of what Visual ReCode can do.

Try Visual ReCode