Server side WCF

[jan-johansson-mr]

Hi,

I'd like to start a thread to have a dialog about server side WCF on .NET Core. For me the WCF stack is quite impressive, and support for server side WCF on .NET Core would be fantastic. Please feel free to add your opinions to the thread.

Here is a list of some of the WCF features (that comes to my mind):

• Throttling
• Reliability
• Ordered Messages
• Bindings
• Instance Management
• Behaviors
• Transactions
• Security
• Discovery
• Metadata Exchange
• Extensibility

These features and more are for me very desirable, but some might be harder to support (e.g. WCF transactions relies on MS DTC (as fas as I know), but transactions enabled communication on a server side is a very important feature).

I hope you're as excited as I am about WCF, and even more so for a server side WCF on .NET Core.

[damianh]

@blowdart +1 for locking. It's going nowhere.

[ccicchitelli]

Damian since you have no skin in the game and are being the most divisive here, I'd suggest banning you before locking those of us with business needs for WCF out of the WCF thread...

[bwatts]

This is about cross-platform WCF, as it is still available on the full fx, correct?

It does not read as an indictment of WCF, its utility, programming model, or popularity.

There is a valid question of whether the effort to de-Windows WCF is a sound investment. Given that it has the W right in the name, my instinct says it's not.

[damianh]

The business needs have been expressed and the alternatives + market direction have been presented.

I have lots of skin in the .net game. I strongly feel that WindowsCF has no place in .net core for it to be competitive in the cloud landscape and for the type of community it need to (re-)attract.

Its available and supported (but not actively developed) on .net desktop. Continue with that.

Final thing I can say is - look where the puck is going.

[shamusfuller]

@sapiens yes!

And, that has been a continuing issue. Like any other large organization, we can expect that MS will not always have their message completely aligned with reality. Remember way back when WCF came out? MS marketed it as being 'all about web services'. Which, in fact, they had invented something completely different. WCF had almost nothing to do with web services. And yet, that fact remain lost even today. Look how many references to web services and SOAP have been made in this thread alone! WCF is actually an extensibility model, an extensible interception based pipeline. the first component oriented platform.

I have had some interesting conversation with 'thought leaders' that originally said WebAPI was the wave of the future and that WCF / Service Fabric / etc was not needed. Those are also some of the same people that delivered addresses this year at conferences you all know of on those very topics: WCF / service fabric etc. It's not immediately obvious to everyone that not everything can be done over raw http interactions.

So, yes, you have been given recommendations. But, you have to decide for your scenarios what is best. And I do use WebAPI, but, for a very specific purpose. Same can be said for WCF, Service Fabric, asp.net, etc. They're complimentary to each other but are very different things used for very different purposes and not really equatable or 100% comparable to each other in terms of feature sets or usage scenarios.

[websitewill]

That's a fair point and the topic of renaming it, IIRC, came up in this thread. About the only part of WCF that is really "windows-specific" is the fact that it can very seamlessly interact with MSMQ via an OOTB binding - something that could be made an auxiliary package. If you are targeting MSMQ you aren't going to target .NET Core anyway, so that would be just fine to use regular .net anyway. Everything else has a corollary in non-windows, AFAIK.

On the other hand, if I did target .net core but still wanted to host on windows instances, I want the ability to just configure a binding to leverage MSMQ (along with bindings for other queue techs such as Rabbit, Zero, Azure, SQS, etc). Nothing in my actual code needs to care, at all. The beauty of WCF.

On Tue, Jan 9, 2018 at 12:33 PM, Bryan Watts notifications@github.com wrote:

This is about cross-platform WCF, as it is still available on the full fx, correct?

It does not read as an indictment of WCF, its utility, programming model, or popularity.

There is a valid question of whether the effort to de-Windows WCF is a sound investment. Given that it has the W right in the name, my instinct says it's not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/wcf/issues/1200#issuecomment-356356588, or mute the thread https://github.com/notifications/unsubscribe-auth/ASs0gW593de-r-kJPgfdh6LqWO5bkBJmks5tI6L8gaJpZM4Ikmmx .

-- Will Comeaux websitewill@gmail.com LinkedIn http://www.linkedin.com/pub/wilmer-comeaux/43/14/404?trk=shareTw Twitter https://twitter.com/wilmercomeaux Facebook http://www.facebook.com/WilmerComeaux

[shamusfuller]

look where the puck is going.

A lot of us were here when they dropped the puck into the game and we've been watching the puck the whole game and we also know where it goes next. I can use my WCF in service fabric. I could use my .net in WCF. I could use my COM in .net.

[ccicchitelli]

Don't let the marketing confuse you, there is nothing that is coupled to Windows that must be coupled to Windows. That's all the name is - marketing.

[forki]

@websitewill

Anyone who thinks Microsoft has "moved on" obviously hasn't talked with any of the teams building Azure

I'm doing a lot azure. zero WCF on the outside. AFAIK the stuff I'm using is also not using much wcf on the inside. I have no data to proof that, but just one simply argument: everything I use is moving over to core. If these parts of azure would rely on wcf that much, then core would support WCF already.

[darrelmiller]

As someone who works as a dev at Microsoft on Azure services and has spent a significant part of the last 18 months building software that helps customers who have SOAP based services, let me offer my perspective with hopefully no judgement on the value of the tech. I think the folks who are hoping they can convince Microsoft to build WCF style services in .NET Core are wasting their time. Your time would be better spent working together on an simplified OSS version of WCF.

I'm not from the .net team, so my opinion is just that but when I needed a WSDL parser to do my work, I wrote a new one instead of depending on WCF. My 2c.

[ccicchitelli]

"Your time would be better spent working together on an simplified OSS version of WCF."

If by that you mean writing it from scratch, then that defeats the entire purpose of asking for this.

If instead you mean the community should maintain WCF going forward, then by all means, send me a link to the compilable source code and I'll have the GitHub project spun up in an hour, and a version running without MSMQ on .NET Core an hour after that ;)

[popcatalin81]

Your time would be better spent working together on an simplified OSS version of WCF.

I could do without SOAP if need be, but I still would like a communication framework with automatic services + automatic proxies suited for RPC, which is configurable and supports a wide array of security and transport options and which comes out of the box in .Net Core.

[scotthurlbert]

You do know it's the first week of 2018, right?

On Jan 9, 2018 9:06 AM, "Damian Hickey" notifications@github.com wrote:

Sure thing @websitewill https://github.com/websitewill

[image: image] https://user-images.githubusercontent.com/57436/34733184-c5d451e6-f567-11e7-95fa-5e6139c5557a.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/wcf/issues/1200#issuecomment-356348769, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo_EknIjEksxYL1ArkzlWw63lFuloQRks5tI5yTgaJpZM4Ikmmx .

[blowdart]

OK we're done here, and that makes me sad.

People want WCF because they're connecting to systems outside of their control, or for back compat, or for the things REST simply doesn't do. Berating them to move to REST when it's impossible for them is neither clever nor helpful.

I will remind you that we have a code of conduct which includes prohibitions on

• Personal attacks
• Trolling or insulting/derogatory comments

Please read it and understand why we have this in place.