> when some Fortune 500 start to complain rather loudly
Not sure it’s such a huge deal, .NET core already has the most complex parts of the WCF. It has fast async TCP and named pipe streams. It has .NET binary XML support, DataContractSerializer, XmlDictionaryReader, XmlDictionaryWriter classes, technically IMO better than protocol buffers: no foreign languages, similar level of performance, convertable to/from text XML if you want a human readable format for easier debugging.
When I needed RPC server in a Linux app written in .NET core, I wrote my own WCF-like thing. I’ve made a T4 template which generates requests/response & envelope classes, and channel factories, using compile-time reflection (EnvDTE stuff) of my service contracts. Took me a few hours. These Fortune 500 companies can probably afford doing the same when they need RPC in .NET.
Nope, usually IT is a cost center, it isn't the main business of the Fortune 500 and if it works, has been battle tested in production, there are zero reasons to rewrite it, just because someone is feeling modern without offering a painless migration path.
Not sure it’s such a huge deal, .NET core already has the most complex parts of the WCF. It has fast async TCP and named pipe streams. It has .NET binary XML support, DataContractSerializer, XmlDictionaryReader, XmlDictionaryWriter classes, technically IMO better than protocol buffers: no foreign languages, similar level of performance, convertable to/from text XML if you want a human readable format for easier debugging.
When I needed RPC server in a Linux app written in .NET core, I wrote my own WCF-like thing. I’ve made a T4 template which generates requests/response & envelope classes, and channel factories, using compile-time reflection (EnvDTE stuff) of my service contracts. Took me a few hours. These Fortune 500 companies can probably afford doing the same when they need RPC in .NET.