WCF in .NET Core works on one side only. The WCF client libraries are supported on modern .NET, including .NET 10, but the WCF server isn't part of modern .NET. To host a WCF service there, you have three routes: CoreWCF, gRPC, or a rewrite as an ASP.NET Core Web API.
Each route keeps different things. CoreWCF keeps SOAP contracts and existing clients, but only part of WCF. gRPC keeps the RPC style and changes the wire format. Web API changes the most. This post sets out Microsoft's support position for each piece, and what each route keeps and loses.
- The WCF client is supported on modern .NET as NuGet packages. The WCF server isn't part of modern .NET.
- Microsoft names two paths for WCF services: CoreWCF, to keep existing clients working, and gRPC. ASP.NET Core Web API is a third.
- CoreWCF 1.9 is supported on .NET 10 until 14 November 2028. Support for CoreWCF 1.8 ended on 24 October 2026.
- CoreWCF covers a subset of WCF. Check each binding and feature you use against CoreWCF's own documentation.
Is WCF supported in .NET Core?
Half of it is.
The WCF client is supported. Microsoft's WCF Client support policy describes it as "the .NET version of WCF client libraries" that "enables applications built on .NET to communicate with WCF or CoreWCF services." It ships as NuGet packages from the dotnet/wcf repository, including System.ServiceModel.Http for BasicHttpBinding, System.ServiceModel.NetTcp for NetTcpBinding, and System.ServiceModel.Federation. The repository calls itself "a subset of the .NET Framework version of Windows Communication Foundation," and marks the Duplex and Security packages as deprecated: "6.0 is the last release of this package."
The WCF server isn't included. Microsoft's list of .NET Framework technologies unavailable on .NET 6+ says WCF server "can be used in .NET 6+ by using the CoreWCF NuGet packages." In 2019, Microsoft's post .NET Core is the future of .NET recommended "either ASP.NET Core Web APIs or gRPC" to WCF server developers.
Support dates for WCF Client and CoreWCF
Both follow the .NET release they run on.
| Package | Version and runtime | Support ends |
|---|---|---|
| WCF Client | 10.0 | 14 November 2028 |
| WCF Client | 8.0 and 4.10 | 10 November 2026 |
| CoreWCF | 1.9 on .NET 10 | 14 November 2028, or six months after the next major or minor release |
| CoreWCF | 1.9 on .NET 8 or .NET 9 | 10 November 2026, or six months after the next major or minor release |
| CoreWCF | 1.9 on .NET Framework 4.6.2 and later | That .NET Framework version's end date, or six months after the next major or minor release |
| CoreWCF | 1.8 | 24 October 2026 (ended) |
Checked 27 October 2026 against Microsoft's CoreWCF support policy and WCF Client support policy.
Two dates matter right now. CoreWCF 1.8 left support three days ago, so services on 1.8 should move to 1.9. And anything on .NET 8 or .NET 9 runs out on 10 November 2026, two weeks from now. When CoreWCF 1.0 shipped, Microsoft's announcement said "Microsoft Product Support will be available for CoreWCF customers," and the policy keeps a previous minor version supported for six months after a new one, "provided the underlying .NET runtime dependency being used is also supported."
What WCF in .NET Core looks like with CoreWCF
CoreWCF is the closest you get to keeping a service as it is. Microsoft's article on why to migrate WCF to ASP.NET Core gRPC calls CoreWCF "a community effort to bring support for hosting WCF services to .NET," and says it "only supports a subset of WCF's features, and .NET Framework apps that migrate to use it will need code changes and testing to be successful." It's "a good choice if an app has to maintain compatibility with existing clients that call WCF services."
Which subset? Only CoreWCF's own documents can say, and they've changed since 1.0:
- The CoreWCF 1.0 announcement, in April 2022, listed BasicHttpBinding, NetHttpBinding, NetTcpBinding, WebHttpBinding and WSHttpBinding, with WSDL generation, and noted "some WS-* features not supported" on NetTcpBinding and WSHttpBinding.
- The same post listed as not yet implemented: transports other than HTTP and NetTCP, message security beyond Transport and Transport with Message Credentials, distributed transactions, and message queueing.
- The current CoreWCF README lists packages for NetNamedPipe, NetTcp, UnixDomainSocket, MSMQ, RabbitMQ, Kafka, Http and WebHttp.
So some 2022 gaps now have packages. Don't assume the rest have caught up. List the bindings, security modes and behaviors your services actually use, check each against CoreWCF's current documentation, and test against real clients.
WCF vs .NET Core Web API, and where gRPC fits
gRPC keeps the RPC programming model. Microsoft's comparison says "Like WCF, gRPC automatically generates messages and a strongly typed client," and "gRPC has full bidirectional streaming, which provides similar functionality to WCF's full duplex services." What it drops is SOAP: contracts are declared differently and messages use Protobuf, so every existing client has to change. Browsers can't call it directly. Microsoft's page on gRPC in browser apps says "It's not possible to directly call a gRPC service from a browser," and offers gRPC-Web or gRPC JSON transcoding.
ASP.NET Core Web API changes the most: plain HTTP endpoints, usually JSON, with no WCF-style service contract. It suits services called by browsers, mobile apps or partners who'd rather not deal with SOAP.
| CoreWCF | gRPC | ASP.NET Core Web API | |
|---|---|---|---|
| Existing SOAP clients | Keep working, within supported bindings | Must change | Must change |
| Service contracts | Kept, with code changes | Redeclared for gRPC | Rewritten as endpoints |
| WS-* features | Partial; check CoreWCF's docs | No | No |
| Duplex callbacks | Check CoreWCF's docs | Bidirectional streaming | Needs a separate mechanism |
| Microsoft's position | Supported under the CoreWCF policy | A recommended path | Recommended in 2019 for WCF server developers |
Which route fits which service
- Outside clients you can't change: CoreWCF, or keep the service on .NET Framework 4.8 until the clients move.
- Internal calls where you control both ends: gRPC.
- Browser and mobile callers: Web API.
- Services that rely on distributed transactions, or message security beyond what CoreWCF documents: stay on .NET Framework 4.8 for now, or redesign.
Staying on .NET Framework 4.8 is a legitimate choice: it's supported as long as its Windows version is, as covered in .NET Framework 4.8 end of support. For the rest of the application, see how to migrate .NET Framework to .NET 10. WCF services turn up on almost any list of legacy system examples, often on servers with their own deadlines, which we cover in the risks of running end-of-life software.
Sizing the move before you pick a route
The route depends on details that are easy to miss: which bindings each endpoint really uses, who calls it, and whether anything relies on transactions, duplex callbacks or message security. The 30-day assessment is fixed in scope, at a price agreed before we start. Over 30 days we read the service code, its configuration and the architecture around it, map how the services fit together with their clients and data stores, find the hidden architectural debt, and flag the security and compliance gaps, including packages past their support date.
The report says in plain language what is broken and what it would take to fix it, service by service, with the route that fits each one. Your own team can act on it, or we can do the migration as a separate project with its own scope and price. Either way, the report stands on its own.
Email Santosh a short list of your WCF services and the bindings they use.