CoreWCF VS wcf

CoreWCF might be of some use.

You can open a discussion in the CoreWCF repo:

In the later versions you could avoid almost all the XML mess by configuring all of the settings in code. The experience is pretty close to gRPC imo, one plus point is you don't need to learn how to write proto classes. Though you could use protobuf-net for a similar experience. I'm kinda hopeful with CoreWCF, they aim to support more transports (including event gRPC) in the future along with queues other than MSMQ and slowly evolve from being too SOAP specific. There's a lot of potential still for WCF to be a transport agnostic framework that ecompass a lot of transports.

On our end, it's WCF for some servers that haven't been upgraded over. Though it seems we have a path forward for that now with CoreWCF that we're working towards.

There's ongoing work on adding generic queue support. The first two concrete implementations should be MSMQ and RabbitMq from what I recall, though MSMQ will be windows only. But the nice thing about the work is it also opens up other types of message queues for WCF (e.g. Azure Service Bus, RabbitMq, Amazon SQS etc...).

It's seems there's already design work started for a generic queue concept here. I'm pretty interested to see how it goes as well as that'll be a big part for CoreWcf to move forward as a viable choice for greenfield projects and not just a way to migrate existing Wcf projects to Core.

The ongoing .net core port called CoreWcf plans to realize that goal as a future feature on it's roadmap. Where there's plans on adding new transports that didn't exist on .net framework wcf like Grpc, Azure Service bus, Amazon SQS, rabbitmq etc...

If you hit any difficulties or have any problems, feel free to jump on the gitter channel. Details for that are in the repo contributing guide.

https://github.com/dotnet/wcf/issues/4887

Technically speaking WCF is quite a bit more than SOAP, I think this might be a good overview of what people used it for (or maybe use it even now).

This article is wrong. It's hard to write and requires some out of the box thinking, but it's doable. You can see my implementation here. You can't easily implement cancellability though as you can't reset the state after an await as any changes you make will happen in a copy of the Execution Context. It could be done with a custom awaiter which chains a delegate to run before the await continuation so you can reset state on the callers ExecutionContext, but I didn't need that so didn't put the effort in.

MTOM on the client is now in code review in this Pull Request. After that's merged, I'll try to find time to port it to CoreWCF in the next month.

Next in my todo list is to add support for WCF, using CoreWCF. Long term, my goal is to also support GraphQL, SignalR, ODAta and WebSockets

There is another tool xscgen, that does not collapse container types and gets all the "inner types" correct but does not generate the Input/Output types or the client interface and client. dotnet-svcutil has another bug that prevents it from reusing external types.

There is a bug in dotnet-svcutil produces incorrect types and/or annotations when collapsing SOME pure container types into jagged arrays. dotnet-svcutil does not have the option to skip collapsing. During the contract implementation phase, which happens at runtime before the first request (ugh!), the code created viaRefEmit clashes with what the annotations specify and that exception is thrown.

I thought that wcf client exists for core? https://github.com/dotnet/wcf