Way, way back in the early days of .NET and the abortive Windows Longhorn project, one of the underlying technologies was a set of standards that built on the nascent web services model: WS-* and SOAP, the Simple Object Access Protocol. The intent was to build a framework that could deliver service-oriented architectures, where applications published defined service endpoints that could connect them both together and to clients and servers.
Microsoft intended to simplify what could be a complex process, writing WSDL (Web Service Definition Language) endpoint and message descriptions, building those endpoints, and constructing and parsing the XML messages used to connect services. Initially code-named Indigo, Microsoft’s web services tool was one of the key Longhorn technologies to survive the Vista reset, eventually shipping as WCF, the Windows Communication Foundation.
Was the .NET transition the end of an official WCF?
WCF remained a key part of the .NET Framework, but by the time Microsoft and its .NET Foundation partners began redefining .NET and its key APIs for the transition to .NET Core and the unified .NET, its heyday had passed and new technologies like gRPC were seen as the way forward. WCF was deprecated and handed over to the community, and developers working on .NET 5 and beyond were encouraged to look at alternative approaches to build service-oriented architectures.
The move away from WCF in the new .NET was a block to many enterprise migrations and updates. Although the WS-* family of standards may have been left behind by modern web standards and the move to REST and JSON, those XML APIs are still part of many running enterprise applications. That’s because the underlying standards come from enterprise requirements, with implementations handling many of the most important features of secure, reliable, messaging-driven APIs. Outside of technologies like WCF, you must build your own security wrappers for messages and construct and manage message queues. Without WCF, porting existing web services–based code to .NET 5 or 6 would be almost impossible.
Here comes CoreWCF 1.0 with Microsoft support
Although Microsoft felt unable to support WCF in the new .NET, there was still demand for it. An internal proof-of-concept project in 2017 implemented some of the core WCF features on what was then .NET Core but was a long way from feature parity. Microsoft handed this code over to the open source community with the original designer as project lead. Work began in 2019 and was hosted on GitHub. Slowly code was added to the project, but things sped up considerably when a team from Amazon Web Services began adding code to the project, porting several key features. What was to become Core WCF continued to grow, with the project using ASP.NET Core as a target.
It’s now time for Core WCF to get its first major release as it now supports enough of the WCF functionality for users to start porting older code to the new .NET. It’s not all of WCF yet, so the project name has two meanings: it runs on what was .NET Core, and it supports the “core” WCF features. Surprisingly for a community project, Microsoft is offering support for the 1.x releases, tying support to the underlying frameworks. For .NET 5 and 6, that support will initially be tied to ASP.NET Core 2.1 and to .NET Framework 4.7. Support will be for the current major.minor release and will end six months after a new version is released.
Having a supported version of WCF for current .NET releases should give enterprise users the necessary confidence to start moving code from older versions. The resulting upgrade will allow them to benefit from both new development tools and from the security and performance improvements that come from a big upgrade to the underlying .NET platform.
Get started with web services using CoreWCF
The release version doesn’t have full parity with the .NET Framework’s WCF. However, there’s enough here to start bringing across existing SOAP applications, working over HTTP and with tools to generate the service WSDL so your client applications can work with servers. Additional features are planned, and the team provides a road map in its GitHub repository where you can vote for features and provide pull requests with your own implementations.
Using CoreWCF 1.0 is much like working with any modern .NET API. As libraries are now delivered from NuGet, you’ll install CoreWCF as needed. It builds on top of ASP.NET Core, taking advantage of its built-in web server to handle HTTP connections to your service, so it’s best to work in Visual Studio. Begin by creating an empty ASP.NET Core application; you won’t need to build any HTML content, as you’re using this to host your WCF service endpoint.
From the Visual Studio package manager install the CoreWCF HTTP and Primitives packages. Once installed you can start to build your service contracts. These define how your SOAP messages are constructed, with definitions for Service and Data contracts. Usefully, these are much the same as you’d have created using the original WCF, and if you’re porting code from the .NET Framework you can copy and paste between old and new.
With contracts in place, you can set up endpoint bindings in your service, for example, ensuring that your service only uses TLS, setting up the service URL as part of the binding. Finally, configure your ASP.NET Core server to set up the appropriate ports for your endpoints, using its appsettings JSON file. You’re now ready to start building client software, using familiar WCF service references to build code from the WSDL generated by your service.
CoreWCF goes a long way to being a drop-in replacement for the original WCF. There’s a slight learning curve but nothing too great, and although some features aren’t yet supported, we’re already seeing the project respond to community demand and add WS-* features that weren’t supported in the .NET Framework. With a lot of WCF code still in use, it’s good to see a supported route that helps bring that code to newer platforms and the .NET cross-platform world where WCF code can now run on Linux servers as well as on Windows.
CoreWCF is an interesting example of a Microsoft-led community project, going from a proof of concept to a set of libraries that are ready to help you bring .NET Framework WCF applications to .NET 6. It’s even more interesting to see two big cloud competitors collaborating on a tool that supports their enterprise customers. AWS’s commitment to .NET shows in its support for the project and the amount of code it has provided. It’s also clear that the 1.0 release is only a landmark, putting a pin on the point where it’s ready for enterprise use. There’s more to come from an increasingly engaged community supporting CoreWCF’s development.
Copyright © 2022 IDG Communications, Inc.
