In the early days of .NET and the failed Windows Longhorn project, one of the main technologies was a set of standards built on the nascent model of web services: WS- * and SOAP, the Simple Object Access Protocol. The intention was to build a framework to deliver service-oriented architectures, where applications publish defined service endpoints that can connect them both together and with clients and servers.
Microsoft intends to simplify what can be a complex process by writing WSDL (Web Service Definition Language) endpoints and message descriptions, constructing these endpoints, and constructing and analyzing XML messages used to connect services. Originally codenamed Indigo, Microsoft’s web services tool was one of Longhorn’s key technologies for surviving Vista’s reset, eventually coming as WCF, the Windows Communication Foundation.
Was the transition to .NET the end of 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 .NET, its heyday was over with new technologies such as gRPC they were seen as a way forward. WCF was rejected and passed on to the community, and developers working on .NET 5 onwards were encouraged to consider alternative approaches to building service-oriented architectures.
Moving away from WCF in the new .NET was a block for many enterprise migrations and updates. Although the WS- * family of standards may have been abandoned by modern web standards and the move to REST and JSON, these XML APIs are still part of many working enterprise applications. This is because core standards come from enterprise requirements, with implementations handling many of the most important features of a secure, reliable, message-driven API. Outside of technologies like WCF, you need to build your own protective message shells and build and manage message queues. Without WCF, porting existing web-based code to .NET 5 or 6 would be nearly impossible.
Here comes CoreWCF 1.0 with Microsoft support
Although Microsoft thought it could not support WCF in the new .NET, there was still a demand for it. An internal project to prove the concept in 2017 implemented some of the main features of WCF on the then .NET Core, but it was far from parity of features. Microsoft passed this code to the open source community with the original designer as project manager. The work started in 2019 and it was hosted on GitHub. Code was slowly added to the project, but things accelerated significantly when an Amazon Web Services team began adding code to the project, transferring several key features. What was to become the WCF Core continued to grow, with the project using ASP.NET Core as a target.
Now it’s time for Core WCF to get its first big version as it now supports enough of the WCF functionality to allow users to start migrating older code to the new .NET. It’s not the whole WCF yet, so the project name has two meanings: it works on what was .NET Core, and it supports the “core” features of WCF. Surprising for a public project, Microsoft offers support for versions 1.x.tying support to the main framework. For .NET 5 and 6, this support will initially be tied to ASP.NET Core 2.1 and the .NET Framework 4.7. Support will be for the current major.minor version and will end six months after the release of the new version.
Having a supported version of WCF for current versions of .NET should give enterprise users the confidence they need to start moving code from older versions. The resulting upgrade will allow them to take advantage of both the new development tools and the security and performance improvements that come from a major upgrade to the main .NET platform.
Get started with web services using CoreWCF
The release version does not have full parity with the .NET Framework WCF. However, there is enough here to start migrating existing SOAP applications running over HTTP and with WSDL service generation tools so your client applications can run on servers. Additional functions and the team are planned provides a roadmap in its GitHub repository where you can vote for features and provide download requests with your own conversions.
Using CoreWCF 1.0 is a lot like working with any modern .NET API. Since the libraries are already supplied by NuGet, you will install CoreWCF as needed. It is based on 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. Start by creating a blank ASP.NET Core application; you will not need to create any HTML content as you use it to host your WCF endpoint.
From the Visual Studio package manager, install the CoreWCF HTTP and Primitives packages. Once installed, you can start building your service contracts. They determine how your SOAP messages are built, with definitions of service and data contracts. It is useful that they are almost the same as you would create with the original WCF, and if you are transferring code from the .NET Framework, you can copy and paste between old and new.
With available contracts, you can set up endpoint binding in your service, for example, by making sure that your service uses only TLS, by setting the service URL as part of the binding. Finally, configure your ASP.NET Core server to configure the appropriate ports for your endpoints using its JSON application settings file. You are now ready to start creating client software using familiar WCF service references to build WSDL code generated by your service.
CoreWCF has come a long way in replacing the original WCF. There is a slight learning curve, but nothing too great, and although some features are not yet supported, we are already seeing how the project meets community demand and adds WS- * features that are not supported in the .NET Framework. Since a lot of WCF code is still in use, it’s a good idea to see a supported route that helps move that code to newer platforms and the .NET cross-platform world, where WCF code can now run on both Linux servers and on Windows.
CoreWCF is an interesting example of a Microsoft-led community project, moving from concept proof to a set of libraries ready to help you bring the .NET Framework WCF applications to .NET 6. It’s even more interesting to see two big competitors’ clouds who collaborate on a tool that supports their corporate clients. AWS’s commitment to .NET is reflected in its support for the project and the amount of code it has provided. It is also clear that version 1.0 is just a guide, placing a pin at the point where it is ready for corporate use. There is more to come from an increasingly committed community supporting the development of CoreWCF.
Copyright © 2022 IDG Communications, Inc.