Modernizing legacy WCF applications to CoreWCF using Porting Assistant for .NET

Many organizations have legacy Windows Communication Framework (WCF) based applications that they have been running for several years on Windows platform. These customers want to modernize to .NET Core to take advantage of the performance, cost savings, and robust ecosystem of Linux.

Today, we announced support of porting WCF application to CoreWCF in Porting Assistant for .NET. Porting Assistant for .NET is an open source analysis tool that reduces the manual effort and guesswork involved in porting .NET Framework applications to .NET Core or .NET 5, helping customers move to Linux faster. It identifies incompatibilities with .NET Core or .NET 5, generates an assessment report with known replacement suggestions, and assists with porting.

With the release of version 1.6, customers can use Porting Assistant to assess and port their legacy WCF application hosted on-premises or on Windows in Amazon EC2 to .NET Core and run them on Windows, macOS, or Linux instances. Customers can even containerize ported applications to Linux containers and run them on AWS Managed Services such as Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Kubernetes Service (Amazon EKS).

In this post, we discuss challenges in modernizing WCF applications and provide a tutorial on using Porting Assistant for .NET to do the compatibility assessment of a sample WCF application and port it to CoreWCF. For the tutorial, we will use a sample application that uses Net TCP binding.

Refer to the documentation and launch blog for Porting assistant for .NET to familiarize yourself with how to use Porting Assistant for .NET. This blog complements those instructions to modernize WCF application to CoreWCF.

Challenges in Modernizing WCF Applications

WCF is used to build service-oriented applications based on the .NET Framework and enables applications to asynchronously send data, packaged as messages, between service endpoints. If you are looking to continuously enhance your WCF application with new features, it is better to migrate from .NET Framework. gRPC and CoreWCF are two recommended ways to modernize WCF apps.

gRPC is a high performant and lightweight remote procedure call framework. Since gRPC implementation and approach are quite different from WCF, moving to gRPC would require a rewrite of your WCF application.

CoreWCF is a port of WCF to .NET Core. This is a community led effort to bring support for hosting WCF services to .NET Core and .NET 5. CoreWCF maintains the API contracts in WCF, allowing customers to port those applications to .NET Core without breaking compatibility with other consumers of their application’s services. The first GA release for CoreWCF was in Feb 2021 and AWS is the second highest contributor to the project, outside Microsoft.

However, porting WCF to CoreWCF is a significant manual effort. As WCF configuration is stored using App.config or Web.Config, porting to .NET Core would require moving configuration to CoreWCF, discovering API’s that support your service configuration, and also registering your services for implementing the dependency injection. Also, CoreWCF is still evolving and supports a subset of WCF functionality. Hence, it is difficult to assess whether the binding, transport, and security models of WCF used in your application are supported in CoreWCF or how much effort is required to port your WCF application. Thus, without proper assessment it is difficult to plan the porting or gauge the timeline required to complete the porting.

Prerequisites

For this tutorial, you should have:

Developer machine with Visual Studio installed.
Porting assistant for .NET installed and configured.
Sample WCF application from Microsoft GitHub samples.

Step 1: Verify existing service endpoints

Before porting to CoreWCF, let us first test the WCF application using the following steps:

Open the WCFTCPSelfHost solution file of the sample application in Visual Studio.
Build the solution to verify it compiles successfully.
Run the solution to start the service. The service will be running on http://localhost:81 as defined in host <baseAddress> section of App.config file.
Run the WcfTcpClient project. It connects to the service endpoint and invoke two operations defined in the service.

You should be able to see the result on client as shown in Figure 1.

Figure 1: Output of WcfTcpClient project

Step 2: Running a compatibility assessment

Now let us assess the sample application for its compatibility with CoreWCF using the following steps:

Launch the porting assistant and click Get started to run an assessment on source project.
Choose Assess a new solution and select WCFTCPSelfHost.sln from your local drive as shown in Figure 2.

Figure 2: Select source solution file in Porting Assistant for compatibility assessment

Step 3: Diving into the assessment dashboard

Once the assessment is complete, you can see the number of ported projects, incompatible packages, incompatible APIs, build errors, and porting actions. In Figure 3 you can see that the sample application has three projects, 8 out of 26 APIs used in the application are incompatible and has four suggested porting actions.

Figure 3: Assessed solutions compatibility overview

Select the project and choose View Details to see the full compatibility assessment report. The assessment report is divided into five sections or tabs – Projects, Project references, NuGet packages, APIs, and Source files.

Projects tab displays the breakdown of incompatibilities and ported actions per project as you can see in Figure 4.

Figure 4: Compatibility assessment dashboard of a solution

The Project references tab shows a graphical view of the package dependencies. The Nuget packages tab provides details of the compatible and incompatible dependencies, and suggested replacements if available. The APIs tab lists the incompatible APIs, what package they are in, and how many times they are referenced. You can see the list of eight incompatible APIs for the assessed application in Figure 5. Source files lists all of the source files making up the projects in the application, with an indication of how many incompatible API calls can be found in each file.

Figure 5: Incompatible APIs with suggested replacement

Step 4: Port the application using assisted porting

Next, let us port the solution to CoreWCF using the following steps:

Select all projects and choose Port Project as shown in Figure 6.

Figure 6: Select projects to Port
Next you will be prompted to choose the porting location. You have the option to “Modify source in place” or “Copy to new Location”. If you have cloned the repository, select the “Modify source in place” option to compare changes using the git version control system.
Review the configuration for porting, and click Port to start porting your solution to CoreWCF. Note: In Version 1.6, the porting assistant only supports .NET Core 3.1.0 for WCF projects.

The process may take a few minutes to finish depending on the size of the project. After the porting is completed, you will see CoreWCF solution under assessed solutions on the dashboard.

Figure 7: Assessment overview after porting

Step 5: Compare code changes

Porting assistant for .NET added a code translation feature that relies on the predefined set of rules and actions. It finds those patterns in the code and updates the code accordingly. It identifies common issues such as usage of Entity Framework or ASP.NET MVC and makes changes to the source code to reduce the manual work needed for porting.

New set of rules has been added to identify usage of WCF and update the code for CoreWCF compatibility. You can verify that the files changed automatically by the Porting Assistant using Git Changes in Visual Studio as shown in Figure 8.

Figure 8: Automatic code changes done by Porting Assistant

Let us review the code changes done by Porting Assistant for WCF Projects:

Updates the project file to target .NET Core 3.1 and adds the required nuget packages to the project as shown in Figure 9.

Figure 9: CoreWCF compatible project file
Updates the relevant source files to use the new namespace for CoreWCF and Microsoft.AspNetCore.
Updates Program.cs to configure WebHostBuilder for using Kestrel to listen on Net TCP. In Figure 10, you can see NetTcp is configured to listen on port 8000. This is a significant change from WCF as it used to initiate a service host to listen for messages from the client.

Figure 10: Updated Program.cs after porting to CoreWCF
Adds Startup.cs file to initiate the configuration of CoreWCF service.

Figure 11: Newly added Startup.cs file after porting to CoreWCF
Adds corewcf_ported.config used in the Startup.cs to get the service model configurations.
Archive files that are no longer needed for example AssemblyInfo.bak and Appconfig.bak.

Step 6: Manual code changes

We deliberately used an application with minimal business logic for this tutorial to focus on the code changes required specifically for CoreWCF compatibility. The business logic in your application may require additional code changes for .NET Core compatibility based on the complexity of your application.

The loading of configurations is different in CoreWCF compared to WCF projects. As the service contract is defined in a separate library, we need to provide full assembly name in the endpoint contract. Update corewcf_ported.config file in WCFTCPSelfHost project as shown in Figure 12.

Figure 12: Adding full assembly name to corewcf_ported.config

As we have ported WcfTcpClient project to .NET Core, we need to update how it calls the service endpoint of the ported service. Update program.cs to add System.ServiceModel namespace and change the Service1Client default initialization to the following code:

Service1Client wcfClient =
        new Service1Client(
                              new NetTcpBinding(SecurityMode.None),
                              new EndpointAddress(
                                     "net.tcp://localhost:8000/Service1"
                                        ));

Figure 13: WCF Client code changes

Step 7: Test ported CoreWCF application

Finally, let us test the ported application using following steps:

Build the ported CoreWCF solution to verify it compiles successfully with new dependencies.
Run the solution to start the service. The service will be running on net.tcp://localhost:8000/Service1.
Run the client project. The client should be able to successfully connect with service endpoint and invoke the two operations and display the result as shown in Figure 14

Figure 14: Output of WcfTcpClient project

Conclusion

In this post, we showcased the process of porting legacy WCF application to CoreWCF using Porting Assistant for .NET as a standalone tool. Porting Assistant for .NET is also available as a Visual Stu dio extension for developers preferring to remain in their familiar development environment.

With the release of version 1.6, Porting Assistant also added support for porting Open Web Interface for .NET (OWIN) and system.web.mvc applications to .NET Core. Using Porting Assistant reduces the manual changes in the source code and accelerates the pace at which these legacy .NET framework applications can be modernized. This gives customers the ability to run their applications on Linux to improve performance, increase security, and reduce the license spend on Windows.

Read .NET blog supporting the community with WCF OSS projects to know more about the roadmap for CoreWCF projects. Refer to CoreWCF GitHub repo for issues, discussion threads and feature requests.

If you need support with modernizing your legacy WCF application using Porting Assistant, contact us at aws-porting-assistant-support@amazon.com.

AWS can help you assess how your company can get the most out of cloud. Join the millions of AWS customers that trust us to migrate and modernize their most important applications in the cloud. To learn more on modernizing Windows Server or SQL Server, visit Windows on AWS. Contact us to start your migration journey today.

Microsoft Workloads on AWS