CoreWCF is the service half of WCF, ported to .NET Core

A port with one job: move the server side off .NET Framework

The README is short and the scope sentence is the whole project. CoreWCF is a port of the service side of Windows Communication Foundation to .NET Core, and the stated goal is to enable existing WCF services to move to .NET Core.

Read that phrasing carefully, because it sets both the value and the limit. This is server side only, and it is aimed at services you already have. A WCF client that needs to talk to a .NET Framework service, or a new API written from scratch, is not what this repository is for. The value is entirely in not rewriting a working service contract, its bindings and its hosting configuration.

The project lives under the CoreWCF organisation with the description "Main repository for the Core WCF project", and its topic tags are only corewcf and wcf. There is no homepage field set, which is consistent with a project whose centre of gravity is the NuGet packages and the `Documentation/` folder rather than a marketing site.

The licence is MIT, with a LICENSE file at the root and a SECURITY.md for coordinated disclosure. The repository is not archived, and the last push was on 2026-08-28.

The build infrastructure is visible at the top level and is Windows centric, as you would expect from a project whose input was a Microsoft framework. There is `azure-pipelines-ci.yml` and `azure-pipelines.yml`, two solutions named `CoreWCF.sln` and `CoreWCFTemplates.sln`, and a `Directory.Packages.props` alongside `Directory.Build.props` and `Directory.Build.targets`, which is the central package management pattern for keeping every project on the same dependency versions.

Thirteen packages, and the package name tells you the binding

The README publishes a table of released packages from NuGet, and the naming is the most useful thing about it. Each package is one binding, one transport or one hosting concern, which lets you take only what a given service exposes.

`CoreWCF.Primitives` is the foundation. `CoreWCF.ConfigurationManager` is the package listed for configuration support. `CoreWCF.Templates` provides project templates.

Then come the transports. `CoreWCF.NetTcp` is the TCP transport that WCF services on.NET Framework often expose. `CoreWCF.WebHttp` is the REST style binding. `CoreWCF.NetNamedPipe` is for same machine named pipe endpoints, and `CoreWCF.UnixDomainSocket` is the local domain socket variant, which is what you would reach for on Linux.

Then the message queues: `CoreWCF.MSMQ` for Microsoft Message Queuing and `CoreWCF.Kafka` with its `CoreWCF.Kafka.Client` counterpart, plus `CoreWCF.RabbitMQ` and `CoreWCF.RabbitMQ.Client`.

That broker split is the clearest sign of how the project has grown.

Note the `.Client` suffix pattern. In both the Kafka and RabbitMQ cases the client side is a separate package from the service binding, so a project that only sends to a broker does not need the service binding and the other way round. Whether that same split exists for MSMQ is not stated in the README.

The README also lists community packages, including `AWS.CoreWCF.Extensions` and `AWS.WCF.Extensions`.

The repository layout is a solution, not a library

The top level entries tell you how to work on this project, and also what a consuming team should ignore.

`src/` is the source. `Documentation/` is the documentation that ships with the project. `templates/` corresponds to the `CoreWCF.Templates` package and the second solution file, so template changes are versioned and tested separately from the runtime. `config/` is build and tooling configuration. `resources.props` and `resources.targets` are the shared version and resource plumbing, and `version.json` is the single source of the version number. `nuspec.props` is how package metadata is produced. `corewcf.snk` is the repository's strong name key file. `coverlet.runsettings` is the code coverage configuration. `testEnvironments.json` describes the environments the test suite runs against.

`CONTRIBUTING.md` and `SECURITY.md` sit at the root, so there is a documented contribution and disclosure path.

For a consumer, the actionable detail is that nothing in that list is something you configure. CoreWCF is consumed as NuGet packages, not by cloning and building, and the two solution files exist for people working on CoreWCF itself. The README does not document a local build procedure, so a team that wants to run the test suite should follow `CONTRIBUTING.md` rather than guess at commands, and the `Documentation/` folder is the reference for hosting configuration.

Release lines are moving in parallel, and the tags are not in order

The release list is where this project looks least like a typical single line library.

Three tags appear in the visible window: v1.9.0 on 2026-04-24, then v1.8.1 and v1.9.1 both on 2026-06-16, the second a minute or two after the first by timestamp. Two maintained minor lines is a pattern you see when a project supports more than one supported .NET baseline, since a fix or a feature can only land on the line that targets a runtime the customer still uses.

For a consumer this has a concrete consequence: pick a minor line deliberately and upgrade inside it. Moving from v1.8.x to v1.9.x is a decision about supported runtimes, not a routine bump, and there is no changelog in the README to tell you what changed.

The gap between the last release and the last push also deserves a note. Tags stopped in June 2026 while the last push was on 2026-08-28, so work is landing on the default branch without a tagged release in the visible window. That is normal for this kind of project and it is also why pinning an exact package version, rather than floating, is the safer habit for a service that has to keep running.

What CoreWCF is not, and the honest cost of the port

The clearest way to state the limit is by naming what a port does not bring. The README describes a port of the service side of WCF to.NET Core, and it does not claim binding parity, feature parity, or a compatibility matrix for anything it does not name. Any of the WCF features your service uses and that does not have a CoreWCF package is a gap you will meet during migration, not after.

The transport packages show the shape of that risk. Named pipes and MSMQ exist as Windows era transports; the local domain socket and the two broker packages exist for the Linux and container world. A service that mixes, say, NetTcp with MSMQ and expects identical behaviour on Linux has to be checked against both packages before anything else.

The alternative approaches are worth naming. The README does not compare CoreWCF with other hosting or migration approaches. CoreWCF is the option for organisations where the client side is fixed by something they do not control, and it is a poor choice for a green field service.

One caveat on the evidence available here: the README does not document a migration tool, a compatibility checker or a list of unimplemented bindings, so the scope of a port has to be established by reading the package table and testing your own service rather than by trusting a completeness claim.

Editorial conclusion

Adopt CoreWCF if you operate an existing WCF service contract and need it hosted on .NET Core, and install only the bindings you actually expose, starting with CoreWCF.Primitives plus one transport package. Do not adopt it to write a brand new HTTP API, since the repository describes it as a port of an existing service model rather than a new framework, and it will not carry the WCF client side. Verify first against your own binding inventory, because the README does not claim full binding parity, and note that the newest tags v1.8.1 and v1.9.1 were both published on 2026-06-16 while the last push was on 2026-08-28.

Frequently asked questions

Official sources

1. CoreWCF/CoreWCF on GitHub
2. Issues
3. License: MIT
4. README
5. Releases