Can WCF services run on .NET 10?

Not as classic WCF. The server side of WCF was never ported to modern .NET. To host SOAP services on .NET 10 you use CoreWCF, a .NET Foundation port that Microsoft supports, and CoreWCF 1.9 is supported on .NET 10 until 14 November 2028 or six months after the next release. The alternative is rewriting the service as gRPC or a REST API on ASP.NET Core.

Is CoreWCF supported by Microsoft?

Yes. Microsoft provides product support for CoreWCF under a published policy, last updated in June 2026. Support follows the underlying .NET version and the latest minor release. CoreWCF 1.9 on .NET 10 is supported until 14 November 2028 or six months after the next release. Only five packages are covered: Primitives, Http, NetTcp, WebHttp and ConfigurationManager.

Should I replace WCF with gRPC or REST?

Use gRPC for internal service-to-service calls between applications you control, especially where you use netTcpBinding today, because it is contract-first, compact and supports streaming. It cannot use Windows authentication. Use REST for browsers, mobile apps and external partners, because any HTTP client can call it and OpenAPI documents it. Keep CoreWCF only for SOAP clients that cannot change yet.

Can a .NET 10 application call an existing WCF service?

Yes. Microsoft's WCF Client packages, such as System.ServiceModel.Http and System.ServiceModel.NetTcp, let modern .NET applications call both WCF and CoreWCF services. WCF Client 10.0 supports .NET 10 until 14 November 2028. The libraries are a subset of .NET Framework WCF, so test unusual bindings and security settings early. WCF Client 8.0 reaches end of support on 10 November 2026.

WCF Migration Guide: CoreWCF, gRPC or REST?

Q: Can a browser call a gRPC service?

Not directly. Browsers do not give web pages the level of HTTP/2 control a gRPC client needs. gRPC-Web is a browser-compatible variant, but browser clients can only make unary and server-streaming calls. ASP.NET Core also offers gRPC JSON transcoding, which exposes the same gRPC service as a JSON API that browsers and partners can call like any REST endpoint.

WCF server is not part of modern .NET, so a WCF service cannot simply be retargeted to .NET 10. Your .NET 10 code can still call WCF services through Microsoft’s supported WCF Client packages. To host services on .NET 10, use CoreWCF when external SOAP clients cannot change, gRPC for internal service-to-service traffic, and a REST API for browsers and partners. Larger estates often need more than one of the three.

Is WCF supported on .NET 8 and .NET 10?

It depends which half you mean. As Microsoft’s .NET Blog put it when CoreWCF launched, .NET Core 3 and later supported the client-side WCF APIs but not the server-side ones. The client is a supported product today. The server never made the move.

Component	Status in October 2026	End of support
WCF Client 10.0 (System.ServiceModel.* packages)	Supported on .NET 10	14 November 2028
WCF Client 8.0 and 4.10	Supported on .NET 8 and .NET 9	10 November 2026
WCF services on .NET Framework 4.8.1	Supported as a .NET Framework component	Follows the Windows version it runs on
WCF services on .NET 8 or .NET 10	Not available	Use CoreWCF, gRPC or REST
CoreWCF 1.9	Supported by Microsoft on .NET 10	14 November 2028, or six months after the next release

The client packages include System.ServiceModel.Primitives, Http, NetTcp, NetNamedPipe and Federation. Microsoft describes the client libraries as a subset of the .NET Framework version, so test anything unusual in your client configuration early. If you still run .NET 8 clients, WCF Client 8.0 support ends with .NET 8 on 10 November 2026. The Microsoft end-of-support calendar lists the other dates that land around it.

What is CoreWCF, and does Microsoft support it?

CoreWCF is a port of the service side of WCF to modern .NET. It is a community project under the .NET Foundation. Microsoft nonetheless provides product support for it, and its CoreWCF support policy, last updated in June 2026, ties that support to the .NET version underneath. CoreWCF 1.9 was released in April 2026 and is supported on .NET 10 until 14 November 2028 or six months after the next major or minor release. Support for CoreWCF 1.8 ends on 24 October 2026.

Read the small print on scope. The policy names five supported packages: CoreWCF.Primitives, Http, NetTcp, WebHttp and ConfigurationManager. The repository publishes other packages, including MSMQ, Kafka and RabbitMQ transports, that are not on that list.

Feature coverage is also a subset. At the 1.0 release Microsoft listed BasicHttpBinding, NetHttpBinding, NetTcpBinding, WebHttpBinding and WSHttpBinding as supported, with some WS-* features missing on the last two. Distributed transactions, message queuing and message security beyond transport-with-message-credentials were not implemented. Later releases added WS2007HttpBinding and issued-token credentials for WSHttpBinding. I found no release note adding WS-AtomicTransaction, so treat distributed transactions as unsupported until you have tested your own configuration.

Microsoft’s GitHub Copilot upgrade agent now includes a skill for moving WCF services to CoreWCF. It converts hosting, configuration, bindings, behaviour extensions and APM-style contracts, which is a reasonable start on the mechanical work.

When should you replace WCF with gRPC?

gRPC is the natural successor for internal service-to-service calls, especially where you use netTcpBinding today. It is contract-first, with a .proto file that generates both the server base class and a strongly typed client. Messages are compact binary Protobuf over HTTP/2. It supports streaming in both directions and passes deadlines and cancellation through the call chain.

The limit is the browser. Microsoft’s documentation says a browser cannot call a gRPC service directly, because no browser exposes enough control over HTTP/2 requests. gRPC-Web works around this, but browser clients can only make unary and server-streaming calls. ASP.NET Core gRPC services hosted on IIS or Azure App Service also don’t support bidirectional streaming. gRPC JSON transcoding, available from .NET 7, can expose the same service as a JSON API.

Check authentication before you commit. Microsoft’s gRPC documentation states that Windows authentication (NTLM, Kerberos, Negotiate) cannot be used with gRPC, because gRPC requires HTTP/2 and HTTP/2 does not support it. If your netTcp services rely on Windows identities, plan a move to Entra ID tokens or client certificates, or keep those services on CoreWCF for now.

WCF duplex contracts with callbacks usually map well onto gRPC server or bidirectional streaming. For broadcasting to many connected clients, Microsoft recommends SignalR over gRPC.

When is a REST API the better WCF replacement?

Choose REST, built with ASP.NET Core minimal APIs or controllers, when the callers are browsers, mobile apps or external partners. JSON over HTTP is readable, passes through ordinary proxies and firewalls, and an OpenAPI description gives partners a contract they can generate clients from.

REST does lose things WCF gave you by default: a strict schema, generated clients and WS-* features such as message-level signing. List the ones you actually use and decide how each will be replaced before you start.

How do you choose between CoreWCF, gRPC and REST?

Situation	CoreWCF	gRPC	REST
Clients are internal .NET apps you control	Works, keeps the old design	Best fit	Good
External partners with SOAP tooling who won’t change soon	Best fit: same contract, same address	Not an option for them	Only with a new contract and a migration window
Browsers and single-page apps	Poor fit	Only via gRPC-Web or JSON transcoding	Best fit
basicHttpBinding today	Supported	New contract	New contract
netTcpBinding today	Supported, with Windows and certificate authentication	Natural replacement	Possible
wsHttpBinding with WS-* features	Partly supported. Test each feature	No equivalent	No equivalent
Windows authentication	NetTcp built in. HTTP bindings use ASP.NET Core authentication	Not supported. Use Entra ID tokens or client certificates	ASP.NET Core Negotiate
Message security (signed or encrypted SOAP body)	Transport with message credentials. Full message security was missing at 1.0	Transport security (TLS) only	TLS, plus signed or encrypted payloads if you build them
Distributed transactions (WS-AtomicTransaction)	Not implemented at 1.0, none found since	None	None. Redesign with idempotency, an outbox or a saga

The pattern I usually recommend is mixed. Put CoreWCF in front of the external SOAP endpoints that partners depend on, move everything you control to gRPC or REST, and publish a dated plan to retire the CoreWCF endpoints once partners have moved.

How do you migrate WCF services without breaking clients?

Find every client. IIS logs, load balancer logs and service-side tracing show who calls which operation. A forgotten caller is the easiest way to fail a cut-over.
Freeze the contract first. Export the WSDL and XSDs from the running service and treat them as the specification. Working contract-first means the new service is generated from, or tested against, that contract, so namespaces, element order and fault formats stay identical.
Record real traffic. Capture SOAP requests and responses from production or a busy test environment, remove personal data, and keep them as test fixtures.
Turn the recordings into tests. Replay each request against the old and new services and compare the responses, ignoring volatile fields such as timestamps and generated IDs. These are characterisation tests for your service boundary.
Run old and new side by side. Put both behind the same address with a proxy or load balancer, and move operations or clients across gradually. Keep the old service running until its traffic reaches zero.
Version deliberately. Any contract change gets a new endpoint or namespace, such as /v2, with a published retirement date for the old one. Never change a live contract in place.

For the clients you own, move them to WCF Client 10.0 first. They can then call the old WCF service and CoreWCF alike, so client and server migrations no longer have to happen on the same day.

A WCF migration is mostly contract and testing work. Recorded SOAP traffic, replayed against old and new services, is the cheapest insurance you can buy.

If you want a second pair of eyes on your bindings, security settings and client list, the Modernisation Blueprint sets the target for each service and a fixed price for the migration.