Windows Communication Framework: Should You Leave?
by The Inedo Team, on Nov 25, 2020 11:32:58 AM
Windows Communication Framework (WCF) may be deprecated in .NET 5+, but it doesn’t mean your applications are going to be left out in the cold. Just like Web Forms and other .NET Framework technologies, your WCF applications will continue to work for a long time. In fact, WCF will likely work for the next two decades thanks to .NET Framework being considered part of the windows operating system.
But that doesn’t mean you have to stick with WCF for the rest of the .NET Framework support period either.
Compared to the complex rewrite needed for Web Forms applications, rewriting WCF is almost simple. WCF generally has a dedicated part of the application, instead of running its roots through the whole codebase like Web Forms. Beyond that, WCF has some Microsoft-supported replacements for .NET 5+.
WCF is not necessary to replace immediately, but the planning should begin now. In this article, we will go over the three options to consider as the future for your WCF applications:
But first, what’s even going on here?
What's Happening with WCF?
In short, nothing.
WCF is in the same camp as the “big three” .NET Framework technologies not being brought into the .NET 5+ branch of .NET Core, Web Forms and Windows Workflow Foundation. These three technologies are not dying overnight, because they are tied to the lifecycle of .NET Framework, which is tied to the lifecycle of the operating system on which it runs. Because of this, .NET Framework will actually be supported far beyond the support cycle for .NET 5.
Microsoft is not dropping it off the face of the earth, but they are no longer actively developing it either. Depending on what .NET Framework technology you use and how you use it, this may or may not be a problem.
Here is a quick comparison of each option before we discuss them in detail:
|Option 1: Stay on WCF||Option 2: Use .NET Foundation's CoreWCF||Option 3: Rewrite to gRPC|
|Works with .NET Core||✘ No||✓ Yes||✓ Yes|
|Cross-platform support||✘ No||✓ Yes||✓ Yes|
|Production-ready||✓ Yes||✘ No, team states it still needs work||✓ Yes|
|Microsoft backing||✓ Yes, still part of .NET Framework||✓ Yes, it starts from WCF codebase||✓ Yes, current recommended option|
|Google backing||✘ No||✘ No||✓ Yes, actively developed by Google|
|Active Development||✘ No||Yes||✓ Yes|
Option 1: Stick with WCF until Its End-of-life
What: Do nothing! Leave your WCF applications as they are. If your application is doing exactly what it needs to do right now, WCF not being part of .NET 5 isn’t going to change that.
Limitations: You may confidently choose this option for applications that are not central to your business plan and not currently receiving much development time. As long as the Windows operating system continues to include .NET Framework, WCF will continue to function.
Considerations: If you plan to use WCF long term, you will need to make accommodations similar to those for any legacy application:
- Document it well. WCF is going to be supported for a long time. But, as WCF grows greyer, it will be harder to find developers familiar with the framework. Having a good record of how your specific WCF application works will make it easier for developers not familiar with the framework to understand how you implemented it. From there, they can likely fill in any other gaps online, as information written about WCF is not going to vanish either.
- Pay for the right talent when necessary. It is possible that situations will occur with your WCF application that will require an expert. Developers who are familiar with WCF are only going to get more expensive as we move further into the .NET 5+ era. The most likely scenario where you will need a WCF expert is when .NET Framework stops receiving support. At this point, you will have to switch. While we currently have the luxury of time for any migrations, that may not be the case at the end of the road. If there is a reason that you would have to switch from WCF quickly in the future, it will cost more than if you started planning to now.
- Remember WCF is already a legacy technology. Microsoft has stopped developing it, it lacks the features of a .NET Core technology, and it is possible that WCF is not the best framework for the job anymore.
Not every application will deserve the effort of a migration. Remaining on WCF lets you channel your energy into other, more pressing problems.
Option 2: Wait for CoreWCF
What: CoreWCF is an open source project spearheaded by the .NET Foundation. The goal is not to make a complete port of WCF but to port over the features that are the most used. You might be happy with how your application runs now but want room for improvement in the future. If this is the case, you may want to watch the development of CoreWCF.
Limitations: The team creating CoreWCF have stated that the “project is not yet ready for production.” But it could turn into a production ready port of enough of WCF to work for your application. It will likely have many of the benefits of moving to .NET Core (e.g., cross-platform support, performance improvements, etc.), while still having a few of the issues associated with legacy software (as it is WCF).
Considerations: There are a few things to keep in mind if you’re considering CoreWCF.
- There isn’t much risk in waiting for CoreWCF. If you want to wait for CoreWCF to mature into a production-ready port, no problem. WCF still works (see Option 1). Especially if you’re going to wait for the improvements to .NET Core that will come in .NET 6 or later, waiting for CoreWCF lets you benefit from others’ experiences.
- There is no guarantee that CoreWCF will become a mature product any time soon (or ever). Microsoft donated code for the initial project, but it is still a community-led project. That doesn’t mean they won’t make something great, but it does mean you should keep your expectations in check and carefully consider whether CoreWCF is the best choice, especially for your applications with a long lifecycle.
- CoreWCF is not intended to be a complete port of WCF. It is possible that you use features in WCF that will not be added to the project. In that case, CoreWCF may not be a good solution.
CoreWCF is a promising idea and may allow applications to take advantage of .NET Core while continuing to use a form of WCF. But that assumes that WCF is the perfect tool for the job in the first place. To use a more modern framework, you will need to move away from WCF entirely.
Option 3: Rewrite to Target gRPC
What: gRPC is an open-source, Microsoft-recommended choice for teams building new applications and for applications that still receive a lot of active development.
Limitations: Switching to gRPC will require a rewrite. It will be an easier rewrite than what would be needed for other technologies, because there are tools that significantly expedite the process and because WCF isn’t woven through the entire codebase of an application. But it is still not a casual undertaking. In the short term, this will require upfront expense and time. But in the long term, it might be beneficial to make the change sooner rather than later.
- You'll move to the actively supported framework. Moving to gRPC will allow you to immediately take advantage of improvements made in the .NET Core. Performance improvements, cross-platform support, and microservices are features already central to .NET Core. It is worth taking the time to see if any of the features of .NET Core would benefit your application or your team in the near to mid future. If there is a good reason to switch to .NET Core, then gRPC is a great framework to target.
- You can use a current, popular framework. Targeting gRPC means you get to work with a popular, open-source framework backed by both Microsoft and Google, two of the largest companies in the industry. Finding developers familiar with gRPC will be easier and less expensive in the long term.
The sooner you replace WCF, the more flexibility you will have later. With a modern framework like gRPC in place, you can make other changes for your application without needing to consider whether it would work with .NET Framework. This gives you way more flexibility when considering other frameworks to work with or changing how you host your application.
By frontloading the change now, you prevent yourself from missing out on other changes down the road because you are tied to legacy software. It is hard to guess what the next important shift in software development will be, and you likely will not need to be on the cutting edge. But modern tools and technologies are more likely to work with .NET 5 + and gRPC than .NET Framework and WCF.
The Key Takeaways
You have time to make the right decision for your WCF applications. WCF is not going to vanish just because .NET 5 deprecates it. But the longer you stay on WCF, the greyer it is going to get.
You have three options for WCF’s future:
- You can stay on WCF. Your applications will continue to work exactly how they do today, thanks to the continued support of .NET Framework (though whether that is actually a good thing will vary for each application).
- You can wait and see what happens with CoreWCF.
- You can transition to gRPC if you want the benefits of .NET 5 onwards.
WCF users should focus on prioritizing migration plans with stakeholders and preparing a rough schedule.
First, determine if the application is worth the effort of a migration. If it is, you have the time to figure out which platform to target based on feature set and how long you can wait to migrate. Teams that can wait a longer time can consider both CoreWCF and gRPC as targets, while teams that want to transition sooner should target gRPC. Either way, take care to figure out what is worth the time to even consider migrating, as WCF will continue to work for a very long time.
Making the .NET 5 Migration? Get a Copy of the .NET 5 Migration Guide
Organizations using WCF applications may be considering the migration to .NET 5. We’re building a guide on how to successfully migrate to .NET 5 and beyond. Sign up today to get early access and to share your own feedback and input.