This tip explores the evolution of WCF, highlighting challenges in transitioning from .NET Framework to .NET Core, emphasizing the decline in new WCF services and the persistent maintenance of existing SOAP services like PPSR and eRx due to unresolved defects in WCF client disposal.
Background
WCF for the Real World, Not Hello World is an article published in 2012. Based on the download source of the article, this GitHub repository is for .NET Framework 4.8, along with some .NET Core examples.
Introduction
According to "Client Support for Calling WCF/CoreWCF with System.ServiceModel 6.0 Is Here!", Microsoft has no commitment to full WCF support, but:
- Quick though not so dirty implementation of WCF Client Libraries, along with a few NuGet packages
- A community project CoreWCF
.NET Core WCF Client Example
Please be focused on the following csproj projects:
- RealWorldServiceCoreClientApi.csproj
- TestRealWorldCoreIntegration.csproj
However, not like the counterpart for .NET Framework, app.config is not utilized anymore, and this config file will cause the xUnit VS runner to fail. So I have hard-coded the binding and the address for System.ServiceModel.ClientBase
. Nevertheless in a real world application, it shouldn't be hard for you to create an app level json based config in appSettings.json and use app codes to instantiate respective bindings.
Points of Interest
ClientBase(string endpointConfigurationName)
Since app.config is not utilized anymore in .NET Core, this constructor is just a zombie function prototype which you cannot really use in your .NET Core client app. Apparently Microsoft has begun to terminate the zombie according to issue #5358.
Good Old Days with WCF
I miss the good old days with WCF. Microservices has been a hype for over 15 years. However, supposedly, I had been building microservices implicitly when developing WCF services:
- As a developer, I build WCF service libraries.
- After the release, IT guys will decide how to deploy them through adjusting the configuration file app.config:
- Different combination of service libraries on different hosts
- Different bindings
- Different security
- Versioning
- ...
.NET Framework Runtime along with "WCF Services / XXX Activation" will take care of the rest during runtime. And .NET Runtime can generate forward only non-cache XML parser/writer to handle SOAP streams.
And in a complex enterprise environment, you may have Biztalk in which WCF components are first-class citizen.
Nevertheless, things move on for many reasons, good or bad. The jobs of creating new WCF services have been definitely declining, though existing WCF services like PPSR and eRx are still well maintained for years and new business client applications interacting with these SOAP services are still emerging.
The Defect in WCF Client Remains
Please check:
According to issue #4912, the defect is not yet fixed, so you may still need the workaround that I had suggested in 2011.
History
- 21st November, 2023: Initial version