CoreWCF 1.0: Removing a blocker for migrating from .NET Framework

CoreWCF 1.0: Removing a blocker for migrating from .NET Framework

The CoreWCF project, a port of Windows Communication Foundation (WCF) to .NET Core, just shipped its 1.0 release.

This is not an official Microsoft project, but Program Manager Sam Spencer said that “Microsoft Product Support will be available for CoreWCF customers,” making it semi-official. The likely reason is that many enterprise applications still use WCF, locking them until now into old Windows-only versions of .NET.

Microsoft forked its .NET development platform in 2014, creating an open source and cross-platform version initially called .NET Core and now called just .NET, reflecting the fact that these days it is the mainstream version. The older Windows-only version is known as .NET Framework.

Three years ago, the company stated “.NET Framework 4.8 will be the last major version of .NET Framework,” with future development devoted to .NET Core with the exception of “bug, reliability and security fixes.”

Director of Program Management Scott Hunter added at the time that “after .NET Core 3.0 we will not port any more features from .NET Framework.”

How did we get here?

Huge numbers of enterprise applications were built using .NET Framework and many continue to run. There is little risk of these breaking (at least with respect to the .NET dependencies) since Microsoft continues to ship and maintain the .NET Framework with Windows.

The company’s track record for maintaining old runtimes is good and even applications built with Visual Basic 6 still run: Microsoft stated last year that compiled VB 6 applications remain supported even on Windows 11, although the IDE has been unsupported since 2008.

That said, continuing to use old runtimes is not ideal, especially for applications that are in active development. Developers miss out on performance, productivity and feature improvements, and old frameworks will not keep pace as internet standards evolve.

Migrating from .NET Framework is therefore beneficial, but not always easy. In particular, Microsoft has not ported the Web Forms framework (the original implementation of ASP.NET), nor has it ported Windows Communication Foundation (WCF).

WCF was born as “indigo”, one of the “three pillars of Longhorn”, the version of Windows that eventually shipped as Vista in 2006. It is a large framework for service-oriented applications, including reliable messaging, transactions, and remote objects.

Although it can use multiple transports, the most common one at the time was SOAP (Simple Object Access Protocol) which exchanges structured information as XML and enables service discovery using WSDL (Web Services Description Language).

Oh SOAP simple?

Despite its name, SOAP is not simple. It is also verbose, and there are compatibility issues between different implementations. It is therefore little used today for new projects and the specification is no longer actively developed. Microsoft chose not to port WCF to .NET Core, other than its client library, partly because of its complexity, and likely also because SOAP had fallen out of favour.

Plenty of developers did use SOAP though, thanks to Visual Studio making it easy to build and consume SOAP services without having to tangle with the XML itself. The consequence today is a bunch of enterprise applications that are hooked to SOAP and therefore .NET Framework, and not necessarily trivial to port to using a modern alternative.

CoreWCF implements only a subset of WCF features, excluding things like distributed transactions and message queuing. It does include SOAP though; and Spencer said that “the sweet spot for CoreWCF is to make it easier to modernize server and clients that have a strong dependency on WCF and SOAP.”

It is not intended to revive use of WCF for new applications. AWS is a strong supporter of the project since it enables porting of existing .NET server applications to run on Linux or in containers.

Developer reaction is generally positive. “We have a big part of codebase as WCF services, which are publicly faced and cannot be easily rewritten. Therefore we kind of stuck forever with “classic” .NET Framework,” said one.

Porting does have downsides though, including the risk of introducing new bugs or running into blockers because not all of WCF has been ported. The likelihood is that just as VB 6 applications refuse to die, there will numerous .NET Framework applications continuing to use WCF and SOAP for a while yet, along with a ton of Web Forms applications for which Microsoft currently has no easy solution.