The transition from .NET Framework to .NET 5 is complicated for WCF applications. Microsoft brought some technologies into .NET 5, but many have been left exclusively on .NET Framework, including WCF. This can leave you overwhelmed and confused about how to migrate your application.
But there are ways to reduce problems during attempted WCF migrations. To position yourself for success, you will want to take these actions:
- Audit why you use WCF
- Identify potential complications
- Consider the order of migration
1. Audit Why You Use WCF
An audit may sound overly formal, but it doesn’t have to be. Really, it’s just figuring out why your organization uses WCF. This way, that information can guide how you make decisions throughout the migration process. Do you use WCF to let components communicate for a desktop application? A browser-based application? Do you use WCF for performance reasons? You should ask all of these questions and more before you start.
Once you have a clear idea of why you use WCF, you can start looking into the alternatives. To start, you can look at a list of possible alternatives for WCF we wrote previously. Each of these alternatives has specific strengths and weaknesses that make them good solutions to some problems, but not others:
gRPC: This is the best choice for any desktop application, any application that wants to use RPC style communication, or in situations where performance is the highest priority. But gRPC can be complicated to use with browser-based applications.
ASP.NET Core MVC: If you have a browser-based application, this is an excellent choice. Compared to gRPC, it is much easier to use for browsers and can work with public APIs. But it is not a good choice for desktop based applications as it was not designed for them.
CoreWCF: This is a community port of WCF that is currently in the works. But it is not ready for production environments and has no guarantee of ever being production ready. But if your main reason for using WCF is familiarity, it could be worth considering this choice if you can wait a long time.
For most use cases, gRPC will be a fine choice as it has a performance bump over other alternatives and will work with almost any platform you would use. But there’s no reason to rush picking the target platform. Take the time to consider each platform’s advantages, any experience your developers may have with the alternatives, and discuss this decision with your team before diving right in.
2. Identify potential complications ahead of time
|Part of .NET 5?||Potential Alternatives||Main Migration Complications|
|Web Forms||No||Razor Pages, Blazor, ASP.NET Core MVC||Alternatives require a rewrite, alternatives may not replicate WebForms functionality 100%.|
|Windows Workflow Foundation||No||CoreWF, move to a different workflow framework, drop a workflow entirely||CoreWF is not a complete product, Windows Workflow Foundation projects tend to use many other .NET Framework components, alternatives may require a rewrite, alternatives may not replicate the functionality 100%.|
|WCF||No||gRPC, ASP.NET Core MVC, CoreWCF||CoreWCF is not a complete product, alternatives may require a rewrite|
For many WCF application migrations to .NET 5, you will need to identify other .NET Framework technologies used.
Identify .NET Framework Technologies: This won’t take very long, but you want to be organized about it. Migration for applications only using WCF and WPF will look very different from migrations for Windows Workflow Foundation applications with multiple .NET Framework components communicating with each other through WCF.
Finding Alternatives: If you are using a .NET Framework technology not included in .NET 5, now is the time to pick a target alternative. Picking the right alternative for any other .NET Framework technology should follow the same thought process we laid out for WCF. Know what problems you use the .NET Framework Technology to solve and pick an alternative that best addresses those same problems.
Each .NET Framework technology has complications that can make migration difficult, even if the technology is now part of .NET 5. A key to a successful migration is to know these complications ahead of time. That way, you can discuss the process honestly with your organization and set a realistic schedule. In general, these are the complications you will run into and how much of an effect they will have on the migration process.
This is the main issue for WPF and Web Forms applications. Just because the frameworks have been brought into .NET 5 does not mean that every API, 3rd party library, NuGet package, or external software solution you use for those applications is .NET 5 compatible as well.
One tool that can help identify incompatible dependencies for WPF and WinForms applications is APIport. It is a tool that grades the likely compatibility your solution based on the APIs/packages used. It will return a percentage of components expected to work, and you can get a better sense of the workload required to port your application from there.
Alternative Requires a Rewrite/Major Edit
Most of the alternatives to .NET Framework technologies will require a rewrite. Even parts of WPF and WinForms applications will need to change to work with .NET 5. Here are some simple ways to make a rewrite easier:
Consider the most familiar alternative: Before settling on an alternative to target, audit your team to see if anyone has experience with one of the alternatives. For example, if you are migrating a Web Forms application and 25% of your team has experience with Razor Pages, that should factor heavily into your decision.
Automate where possible: Some edits are required to make WPF and WinForms work on .NET 5, but you can do many of those with Microsoft’s Try-convert tool. For WCF, we make Visual ReCode, which will actually rewrite your application for your target framework (gRPC or ASP.NET Core MVC).
3. Consider the Migration Order
For applications that consist of multiple .NET Framework components, you should take some time to decide what would be the best migration order.
In general, applications that use WCF will want to rewrite that portion of the application first. For example. by switching WCF to gRPC, you switch to a framework that can natively communicate with both .NET Framework and .NET 5 components. This allows you to take the time necessary to finish porting the rest of the project, as no matter what stage each component is at, they will all still be able to work together.
Order matters during each migration as well. Each component will have dependencies that need to be updated in a specific order to ensure the application will work as intended. For WCF, Visual ReCode has a Guided Project Upgrade feature that will determine that order for you.
For Windows Workflow Foundation, it can be a different story. If you decide to use a workflow framework that is not for .NET, you will need to rewrite the whole application, and focusing on rewriting the WCF portion first may not do a lot of good. In these cases, you may want to consider getting external advice from an expert on the alternative solution you plan to replace Windows Workflow Foundation.
Successful WCF Migration Requires Successful Planning
If one thread connects everything we discussed, it is taking the time to plan carefully. The .NET Framework to .NET 5 migration can be difficult, but if you take the time to consider obstacles before they appear, you will have a much better chance at success.
One way to knock down the obstacles of migration is with Visual ReCode. We have accounted for many of the difficulties that come with .NET Core or .NET 5 migration for WCF and made a tool we believe will significantly help organizations navigate the migration process. You can learn more about Visual ReCode in the links below.