You can’t directly port a WCF application to .NET 6. Like .NET 5 the rest of .NET Core, WCF is an unsupported technology and will remain exclusively a part of .NET Framework. But it doesn’t mean it’s not worth migrating. Here, we will discuss why you should consider migrating anyways, choosing .NET 6 over other versions of .NET Core, and the available WCF alternatives.
- Why Should I Migrate to .NET 6 if WCF isn’t an Option?
- Is .NET 6 the Best Version of .NET to Target?
- What are the WCF Alternatives for .NET 6?
- Is Migrating to .NET 6 Easy?
Why Should I Migrate to .NET 6 if WCF isn’t an Option?
I’ll start by just being honest; you don’t have to migrate. Microsoft still supports .NET Framework, and will for as long as it’s part of the Windows operating system. The good news there is it’s available for Windows 11. That should be enough proof to indicate .NET Framework is here for a while. So there’s no need to rush any decisions assuming .NET Framework is going to stop working soon. Instead, realize migrations away from .NET Framework will primarily take place for the two following reasons:
A dependency is losing .NET Framework compatibility. Even if .NET Framework remains supported, it does not mean every plugin or 3rd party library you use will continue working. If a plugin you use stops receiving security updates for .NET Framework versions, you will either need to find a working alternative, migrate the application, or take on some unwanted risk.
You want access to improvements and features made in .NET. .NET Core (especially .NET 6) offers many features unavailable on .NET Framework, such as cross-platform support, improved performance, and more. .NET 6 and beyond is where Microsoft will innovate the .NET ecosystem. Support for .NET Framework will only address security and bug fixes moving forward.
No matter which reason is your primary motivator, some questions need answers before committing to a .NET 6 migration. Let’s cover some of those below.
Is .NET 6 the Best Version of .NET to Target?
For migrations done in the next 18 months, .NET 6 is the best version to target. In short, .NET 6 is the most stable version of .NET Core for the foreseeable future:
.NET 5 support ends May 8th, 2022. The new .NET release cadence alternates between “current” and “long term support” versions. .NET 5 has a support level of a “current” version meaning that its support shelf life was 18 months.
.NET Core 3.1 support ends December 3rd, 2022. .NET Core 3.1 was the previous long-term support version, but is almost at the end of its lifecycle. Even if you are planning to migrate before this date, targeting .NET 6 now will save you a bit of work in the future.
.NET 6 should have a longer support period than .NET 7. As long as Microsoft sticks to its current release plan, .NET 7 should come out in November 2022 and receive 18 months of support. That places the approximate end of support for .NET 7 in May of 2024. .NET 6, on the other hand, has a confirmed end of support date of November 8th, 2024. About six months later.
.NET 6 puts you in the best position to pick a future version. By the end of the .NET 6 support period, we will see the releases of .NET 7, .NET 8, and most likely a preview version of .NET 9. By picking .NET 6 to target now, you get the luxury to investigate the next three versions of .NET before you need to update.
If you are targeting your migration for the end of 2023 though, you should consider .NET 8 the best target. By mid 2023, we should have a preview version of .NET 8, and in early November the official release. It’s also a long-term support release and will likely be adopted by folks already using .NET 6 or .NET 7.
What are the WCF Alternatives for .NET 6?
|gRPC||CoreWCF||ASP.NET Core Web API|
|Development Teams||Microsoft and Google||.NET Foundation||Microsoft|
|Best Use Cases||When performance is king, need flexible framework||When you can wait, want exact WCF experience||Browser applications, when Public APIs are important|
In short, both WCF and gRCP are remote procedure call frameworks with similar goals. Additionally, gRPC has many of the same features, such as an equivalent for WCF’s full duplex services and automatically generated messages. But gRPC is faster, uses less bandwidth (good for a world with data-caps/network restrictions), and directly supported by .NET Core/.NET 6. Even in a world where .NET Core ran WCF natively, most new applications would want to use gRPC anyways.
gRPC is also the alternative that Visual ReCode currently writes to. So, if you want an assisted migration for your WCF application, gRPC is the current way to go.
CoreWCF is another option that has had some updates since I have last written on it. Previously, I stated it was not a good choice for production applications. Now, it depends on your application. Some features of WCF are missing, so it may not be a complete port of WCF functionality for your application. But folks are using it in production applications and it has had consistent updates over the last year. It’s a much improved option at this point.
ASP.NET Core Web API is a good option as well, specifically for browser-based applications. For all the strengths that gRPC has as an alternative, it is not the easiest to use for the browser (it is possible with gRPC web though). As far as the migration process goes… well, we hope to have more news on that later this year.
Is Migrating to .NET 6 Easy?
In general, the more time that passes, the harder the migration becomes. The gulf between .NET Core and .NET Framework will grow larger, less people will be familiar with both technologies to help assist migrations, and resources created for migrations, (like this from Microsoft), will get harder to find. But we aren’t really at that point yet.
Migrating to .NET 6 isn’t much harder than migrating to the previous versions of .NET Core. The only new consideration is that you need to use Visual Studio 2022 for .NET 6. Otherwise, the situation remains the same: WCF migrations are inherently difficult. Any of the alternatives listed above will require some rewriting/adjustments, let alone any changes made to 3rd-party dependencies you use.
This is why we created Visual ReCode, to help automate parts of a complicated process.
Visual ReCode is our Visual Studio extension built to rewrite WCF into gRPC services. If you would like to learn more about how Visual ReCode works, you can take a look at the features page in the link below.