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.

[csharpfritz]

Who would be modifying or extending WCF in .NET Framework? The question was from some interested developers asking if they can write a compatible framework for .NET Core...

Why does the lack of .NET Core support make something deprecated? .NET Framework 4.7.1 was released this week, along with a preview announcement of .NET Framework 4.7.2. New Windows servers are planned, and new Windows clients are planned as well. What was deprecated? Who is saying this framework is incapable? These are not messages you are hearing from our teams.

Jeff

On Fri, Oct 20, 2017 at 3:53 PM, insylogo notifications@github.com wrote:

Nice try, but the source is available but only for reference use, not for modification or extension.

You may view WCF as "extremely stable" and capable, but because of the lack of adoption of .NET Core most people now consider it "extremely deprecated" and incapable.

— 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-338306546, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEy8Q5ZuUIL35_A8elrVPaL3P0NfmBFks5suPowgaJpZM4Ikmmx .

[scotthurlbert]

You may be mis-characterizing history. I have had many conversations over the years about how SO with WCF is the only all-in-one package for services. I've done work in on other platforms where we have to bring together dozens of vendor products to get what .net offers out of the box.

You may not hear people desire it because, in my experience, people are generally a bit cross camp ignorant. I certainly am because its hard enough to keep up with the details of your own camp.

However, as SO matures it becomes clear that what's needed are the features of WCF (hosting, transactions behaviors, auth, interface based, etc etc). The designers of WCF did a unique and amazing job.

I don't really care how tied it is to Windows. That merely sounds like something that needs to be dealt with under the covers.

The question was asked do we want it in .Net core and why and this list contains some of the answers. We do.

On Oct 20, 2017 12:26 PM, "Jeffrey T. Fritz" notifications@github.com wrote:

There are distinct features of .NET that are tightly coupled to Windows: System.Web and WCF as well as WPF and WinForms are four of those frameworks that are not ported to .NET Core for this reason. There are other frameworks and tools in the .NET Ecosystem that can be used for those purposes.

Until .NET Core, there was never a question of being able to run WCF on Linux, and we do not have a compelling reason to enable that. You can run your services in containers, and we are working to further enable that capability with additional features on Windows with .NET Framework 4.7.1 and later.

Jeff

On Oct 20, 2017, at 15:19, Allen Byron Penner notifications@github.com wrote:

Seems like a good enough reason to change the whole .net ecosystem but not WCF... LOL @csharpfritz you too funny

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— 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-338300809, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo_EqrCGeAGT5hiFQQmifOce1s6067kks5suPPvgaJpZM4Ikmmx .

[insylogo]

Reasons it's incapable and should be considered deprecated by the community, compared to other .NET components:

1. Not being part of .NET core means it is not "open source" and nobody outside Microsoft can rewrite it for .NET core.
2. No cross-platform support, which many cite as a primary reason to use .NET core in any application.
3. It cannot benefit from the .NET Core performance gains (of which there are many).
4. Anyone who wants to port their current WCF services to .NET core is going to have to spend a very significant amount of time redesigning their architectures to include all the features they were dependent on and got for free as part of WCF. This is Microsoft putting the onus on the customer to engineer their way out of a Microsoft-caused problem. You guys should be willing to take the hit in order to make your customers lives easier, instead you're here arguing that your customers are wrong.

SQL server and ASP.NET have migrated to cross-platform capable foundations, apparently avoiding your fatalistic, fallacious arguments.

Being excluded from .NET core is a clear message to developers that there will be less and less support going forward, and to avoid using it. It doesn't matter if you release updates every hour on the hour for WCF in the .NET Framework, if it's not part of Core we all can take that as a sign it has no real future. Just like no new software is being written using Silverlight or Windows Forms, WCF will be done in short order.

.NET Core is not being adopted by my team because the lack of WCF support. And if we're not doing it, there are certainly many others doing the same as us. That means less adoption of your very expensive investment in this new technology. This should be more important to you than the investment required to modify WCF.

[iskiselev]

Even placing WCF-based application to docker will require to use ServerCore image (which is huge) - not Nano.

[alfred-c]

Don't get too hung up on the WCF that was designed for Windows n number of years ago. How would you redesign/update "XCF" (X comes after W) to work tomorrow in .NET Core?

I think what the community wants is a mature, out-of-the-box, enterprise-grade, service-oriented programming model for inter-process communications regardless of what platform is hosting the process, whether the processes are local or distributed, whether the process is on a server or mobile or IoT device. Simple enough, right?

It's a tall order for sure, but the WCF team was able to do it in the era of Windows and .NET (so long as the device was running Windows). Rather than unify disparate technologies that existed previously on the Windows platform, the new challenge is to enable communication across any platform with any device anywhere. Changes and different approaches will undoubtedly be necessary and perhaps even an improvement. As developers, why should we concern ourselves with configuration of endpoints or maintaining static proxy code? Why can't we just connect the dots and let the framework negotiate the best way to communicate? As long as any POCO class can be converted to a service with interfaces as service contracts, serializable DTOs as data/message contracts, and behavior modification applied AOP-style via attributes or PnP configuration we should be able to cope with whatever the future brings. This communications channel just needs to work reliably, securely, under every scenario imaginable to be considered enterprise-grade.

The justification for such an endeavor is the same reasons why Microsoft is investing in Azure, to re-position itself for the future. Streaming data to/from mobile devices on the hyper-loop transit or peer-to-peer autonomous-vehicle networks is not out of the realm of possibilities where .NET Core code might find itself someday. The question is whether Microsoft will be ready with a solution for those scenarios or scramble to play catch-up and allowing others to fill the void.

Alfred

On Fri, Oct 20, 2017, 12:46 PM insylogo notifications@github.com<mailto:notifications@github.com> wrote:

Communication Foundation*

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/dotnet/wcf/issues/1200#issuecomment-338305075, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABInQUsmEhxWNNiiHQt1fkzrUOdHIyOEks5suPiPgaJpZM4Ikmmx.

[jan-johansson-mr]

This thread was opened 23rd of May, 2016, about 1.5 years ago, with the subject line "Server side WCF". The amazing responses, from majority of writers, have been of high quality. The participants in the thread have replied several times about why and what, and also with several business cases. There was a survey (with a link) given, bundled with the message (16th of July, 2016):

"The WCF feature team is actively working on roadmap plans for WCF functionality in future .NET Core releases. For next steps, we need your feedback in terms of top scenarios, feature usage and target profiles."

True, the message did not specify if the roadmap was for the client side .NET Core, or for a future server side. I've never seen any result of the survey.

The recent posts suggest that there are no plans for "Server side WCF", and that it will never happen, because of this or that.

Is this the official message from Microsoft? (it's good to have a clear and official message)

To refer to a "read-only" repository is, in my opinion, rather low point, especially to all these fantastic contributors of this thread, many from what I understand have many years of experience using and developing for WCF on .NET Framework.

The .NET Standard and it's implementation in .NET Core is truly amazing! The giant leap from version 1.x to 2.0 was incredible. The community has chipped in with high quality code, increased performance on all levels, even with basic primitives (sorry I can't give you a link, but I've read on several sites about the performance increase and that some was going to be merged back to .NET Framework from all this work). The suggestion of "releasing" (the full) WCF to the community is maybe not such a bad idea...

[scotthurlbert]

Spot on comments from my friend Jan. Thank you.

As an odd coincidence check this out. I've been using Emitter for an IoT project. Emitter is a light weight implementation of the MQTT messaging protocol originally developed at IBM and not in the public domain.

When I first started the project back in the summer I downloaded the Emitter code for the C# .NET Core broker (broker is what MQTT calls the server).

Today I went to see if there were any updates to the server code. I've noticed some issues and rather than fixing them I thought I would check for an update. Nothing.

I couldn't find the project or the source code anywhere. Finally I found the product roadmap for Emitter and it says this:

"Main focus right now is to bring emitter to a production ready state and make sure it can withstand any network partition and scales well. Hence the golang migration, we wanted to take advantage of extensive distributed systems libraries available in Go, ARM and native code. This will be the only maintained version, we will be dropping our C# version and focusing on Go."

Now there are a lot of reasons a team might switch to Go, but their stated reason for the switch is "to take advantage of extensive distributed systems libraries available in Go..."

What are we discussing being missing from the .NET Core libraries? That's right, "distributed systems libraries" or, as it's commonly called on .NET

• WCF.

Jeffrey, you asked for an example and completely by accident just hours later, there it is.

Scott

On Fri, Oct 20, 2017 at 9:38 PM, Jan Johansson notifications@github.com wrote:

This thread was opened 23rd of May, 2016, about 1.5 years ago, with the subject line "Server side WCF". The amazing responses, from majority of writers, have been of high quality. The participant in the thread have replied several times about why and what, and also with several business cases. There was a survey (with a link) given, bundled with the message:

"The WCF feature team is actively working on roadmap plans for WCF functionality in future .NET Core releases. For next steps, we need your feedback in terms of top scenarios, feature usage and target profiles."

True, the message did not specify if the roadmap was for the client side (HTTP only) .NET Core, or for the server side. I've never seen any result of the survey.

The recent posts suggests that there is no plans for "Server side WCF", and that it will never happen, because of this or that.

Is this the official message from Microsoft? (it's good to have a clear and official message)

To refer to a "read-only" repository is, in my opinion, rather low point, especially to all these fantastic contributors of this thread, many from what I understand have many years of experience using and developing for WCF on .NET Framework.

The .NET Standard and it's implementation in .NET Core is truly amazing! The giant leap from version 1.x to 2.0 was incredible. The community has chipped in with high quality code, increased performance on all levels, even with basic primitives (sorry I can't give you a link, but I've read on several sites about the performance increase and that some was going to be merged back to .NET Framework from all this work). The suggestion of "releasing" (the full) WCF to the community is maybe not such a bad idea...

— 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-338363523, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo_EiIMgws8UInsBeEUdyQBIK6M5J8rks5suXVRgaJpZM4Ikmmx .

-- Scott Hurlbert Technical Architect 415-378-9908 scotthurlbert@hotmail.com AIM: scottahurlbert Skype: hurlbert GTalk: scottahurlbert@gmail.com Blogs:

• https://medium.com/@hurlbert
• http://oknowwhatfolks.blogspot.com/
• http://agilecliches.blogspot.com/

[thefringeninja]

Unfortunately I don't think it's that simple. Despite all the warts, net standard 1.x basically worked - all the apis it said it implemented were implemented.

WCF is something else entirely. While some of the bindings are probably easy to implement - HTTP(s)/SOAP - some are going to be impossible - MSMQ. What is everyone's expectation here? Putting on my non technical hat here, if I heard that WCF was getting ported to dotnet core then I would expect all of it to work. Which isn't happening. Unless they decide to support a different set of bindings on linux. That might have merit. They'd have to call it something else though...

At the end of the day, these communication frameworks will come and go. 20 years ago we had DCOM and CORBA, last decade it was WCF, today's new hotness is gRPC, tomorrow ??? BTW does anyone remember what happened to .net remoting?

https://spin.atomicobject.com/2013/02/23/ports-adapters-software-architecture/

[jan-johansson-mr]

To take my non technical hat on, in response to "thefringeninja" :-) ...

There is already an answer to "not supported" on .NET Core today, the exception "Not supported platform", the same can go with anything that might be ported to .NET Core.

That said, the thread already addressed that several technical aspects may not be possible, and that's fine, because WCF is more than a technology set, WCF supports a (service oriented) programming model. Maybe not everything can be translated to .NET Core, but I'm sure a lot of things can be.

I don't think this is so much of a technical issue, it's a business decision. If Microsoft do not prioritize WCF on .NET Core, it's their decision. But maybe the community can chip in, if Microsoft allows (licensing).

As Scott says, there are many alternatives and viable options. However, if you have invested years of knowledge into .NET ecosystem, then I guess you'd be happy to apply your skills on the same ecosystem.

[websitewill]

MSMQ. What is everyone's expectation here? Putting on my non technical hat here, if I heard that WCF was getting ported to dotnet core then I would expect all of it to work. Which isn't happening. Unless they decide to support a different set of bindings on linux. That might have merit. They'd have to call it something else though... DING! Support the windows-specific or Linux-specific bindings as separate nuget packages.

It could be done, certainly.

On Oct 21, 2017, at 4:14 AM, João Bragança notifications@github.com wrote:

MSMQ. What is everyone's expectation here? Putting on my non technical hat here, if I heard that WCF was getting ported to dotnet core then I would expect all of it to work. Which isn't happening. Unless they decide to support a different set of bindings on linux. That might have merit. They'd have to call it something else though...

[scotthurlbert]

Well put WebSiteWill

Joao, you are talking about a binding, not implementing MSMQ. WCF only requires the address and the protocol, not the actual implementation of MSMQ itself. It could be done.

On Sat, Oct 21, 2017 at 4:08 AM, websitewill notifications@github.com wrote:

MSMQ. What is everyone's expectation here? Putting on my non technical hat here, if I heard that WCF was getting ported to dotnet core then I would expect all of it to work. Which isn't happening. Unless they decide to support a different set of bindings on linux. That might have merit. They'd have to call it something else though... DING! Support the windows-specific or Linux-specific bindings as separate nuget packages.

It could be done, certainly.

On Oct 21, 2017, at 4:14 AM, João Bragança notifications@github.com wrote:

MSMQ. What is everyone's expectation here? Putting on my non technical hat here, if I heard that WCF was getting ported to dotnet core then I would expect all of it to work. Which isn't happening. Unless they decide to support a different set of bindings on linux. That might have merit. They'd have to call it something else though...

— 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-338383976, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo_ErhLTmLMg1nibcmg__MAli3JcsDSks5sudCvgaJpZM4Ikmmx .

-- Scott Hurlbert Technical Architect 415-378-9908 scotthurlbert@hotmail.com AIM: scottahurlbert Skype: hurlbert GTalk: scottahurlbert@gmail.com Blogs:

• https://medium.com/@hurlbert
• http://oknowwhatfolks.blogspot.com/
• http://agilecliches.blogspot.com/

[scotthurlbert]

I don't think it's a matter of today's hotness and competing standards. WCF offers a collection of things needed to create industrial-strength / enterprise-strength services.

For example, WCF supports transactions and distributed transactions. This means that architecturally your exposed service can enlist internal services to perform your use case and upon failure the use case service can recover.

When I searched for transactions and gRPC I found this https://groups.google.com/forum/#!topic/grpc-io/1LoCKlhHv3Q. It's a working document so things may have changed, but if it's to be believed the notion of a transaction is just to push the failure back to the client. This means that the client needs all of the compensating failure code and POOF, you're right back to the BIG-BALL-OF-MUD design pattern.

Most services tend to be simple (at first) so even pushing things back to the client (caller) works well at first and seems "easy." Time will tell.

In a similar vein WCF's support of authentication and authorization supports configuration via attributes. It's declarative. This means that auth is separate from the code (if you want it to be) so you get a natural separation of concerns.

I get it. Most people don't need this level of nuance and aren't interested in these architectural concerns. I also know that at enterprise scale, these aspects become issues for everyone.

Take the comments in the link above. The gRPC team set out to build a REST framework. But after examining their actual implementations they found they were all RPC in nature. I've built my fair share of REST apis, but in general I don't use them in my application architectures because what I need are methods, RPC in other words. The community has gone crazy building REST only to find that they need RPC. The same evolutionary process happens with services. You start out just wanting to "make the call" but once you get that working you need security. With security you need auth/auth. With more sophisticated use cases you need transactions, logging, scaling, fault handling, tracing, etc.

I have no doubt that gRPC will work well ... until it doesn't. By then, the commitment will be 100%. Rewrite 2.0 will start, etc. This can happen with WCF as well, so there's no glass houses here, but there are reasons why teams go down these paths. Sometimes it's because of what's not in the framework, sometimes it's because we don't even know we need what's missing.

On Sat, Oct 21, 2017 at 1:14 AM, João Bragança notifications@github.com wrote:

Unfortunately I don't think it's that simple. Despite all the warts, net standard 1.x basically worked - all the apis it said it implemented were implemented.

WCF is something else entirely. While some of the bindings are probably easy to implement - HTTP(s)/SOAP - some are going to be impossible - MSMQ. What is everyone's expectation here? Putting on my non technical hat here, if I heard that WCF was getting ported to dotnet core then I would expect all of it to work. Which isn't happening. Unless they decide to support a different set of bindings on linux. That might have merit. They'd have to call it something else though...

At the end of the day, these communication frameworks will come and go. 20 years ago we had DCOM and CORBA, last decade it was WCF, today's new hotness is gRPC, tomorrow ??? BTW does anyone remember what happened to .net remoting?

https://spin.atomicobject.com/2013/02/23/ports-adapters- software-architecture/

— 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-338374576, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo_En-GghrNum4ZWqyO7BIdml5qUSYGks5suafWgaJpZM4Ikmmx .

-- Scott Hurlbert Technical Architect 415-378-9908 scotthurlbert@hotmail.com AIM: scottahurlbert Skype: hurlbert GTalk: scottahurlbert@gmail.com Blogs:

• https://medium.com/@hurlbert
• http://oknowwhatfolks.blogspot.com/
• http://agilecliches.blogspot.com/

[joerglang]

@Jeff You wrote: Why does the lack of .NET Core support make something deprecated?

For me it goes along the lines like this. Microsoft brings out a complete rewrite of .NET and opens up the door to other OS. It’s not something that was a big problem in the past, as our customers knew that when they hired us the got an MS based solution back and it was not a problem for them, because they were running Windows Servers.

But hey, that was something that was not working for 15 years, but know as we are able to do it, then hey it’s a great thing. And all along every programming magazine (MS related) was only bringing articles of that new thing. And all of the blogs just wrote about .NET Core. So now the developers get the feeling this is the new way to go and get the impression that their old tool is just old.

And yes, then was that little incident with Silverlight. All shiny, all great, not a conference without 80% talks about Silverlight and then it vanished in a puff of haze just like that. That was something that stuck with us. When are they pulling such a stung again? Maybe tomorrow everything should be ServiceFabric and then puff, support for WCF is even gone for the Windows world.

You see, the fact that Microsoft is not willing/capable to port WCF to the new world makes us uneasy. For me personally it doesn’t have to be a complete full port of all aspects of WCF. It doesn’t have to support all bindings. But it should allow us to build SOA applications with transactions, authorization and other good stuff.

In the end my question is: What is .NET Core for?

Why should I start building on the .NET Core platform when even Entity Framework is way behind the EF for the full .NET in regards to functionality? Other stuff like WCF is missing as well. Don’t forget not every developer out there is writing bleeding edge, NoSql, NoConstraints, NoRelations, NoSecurtiy software. Some work on systems that evolved for years and are stable and mature as well.

The question is what those developers say to their managers? Developer: Sir you know, MS hat that new shiny thing, but it lacks some of the functionality we need. Manager: But we need to keep up with the technology or our system won’t be able to run on Windows Server 2019. Developer: We can do, but it means we have to rewrite it for a big part, and if we do that we might need to evaluate if we do it in Java or not.

Joerg

Von: Jeffrey T. Fritz [mailto:notifications@github.com] Gesendet: Freitag, 20. Oktober 2017 21:59 An: dotnet/wcf wcf@noreply.github.com Cc: Jörg Lang jlang@evelix.ch; Mention mention@noreply.github.com Betreff: Re: [dotnet/wcf] Server side WCF (#1200)

Who would be modifying or extending WCF in .NET Framework? The question was from some interested developers asking if they can write a compatible framework for .NET Core...

Why does the lack of .NET Core support make something deprecated? .NET Framework 4.7.1 was released this week, along with a preview announcement of .NET Framework 4.7.2. New Windows servers are planned, and new Windows clients are planned as well. What was deprecated? Who is saying this framework is incapable? These are not messages you are hearing from our teams.

Jeff

On Fri, Oct 20, 2017 at 3:53 PM, insylogo notifications@github.com<mailto:notifications@github.com> wrote:

Nice try, but the source is available but only for reference use, not for modification or extension.

You may view WCF as "extremely stable" and capable, but because of the lack of adoption of .NET Core most people now consider it "extremely deprecated" and incapable.

— 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-338306546, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEy8Q5ZuUIL35_A8elrVPaL3P0NfmBFks5suPowgaJpZM4Ikmmx .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/dotnet/wcf/issues/1200#issuecomment-338307758, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABqRzGV7SVZysHDel2oZorSTl3X4m_8Zks5suPt4gaJpZM4Ikmmx.

[phillip-haydon]

I’m still yet to work for a company that isn’t desperately trying to remove all traces of EF and WCF. So sounds like core is great got me.

[scotthurlbert]

Yes, and how's that working out for them.

https://en.wikipedia.org/wiki/Software_crisis

I agree about EF, but what are they replacing WCF with? You have to understand the power in almost no lines of code. There is just nothing else that can do that. Here is a complete service and hosting in 4 lines of code.

///////////////////////////////////////////////////////////////////////////////////

[ServiceBehavior] public class MySimplestService : IMySimplestService { public string Echo( string pInput ) { return $"I heard you say: {pInput}"; } }

[ServiceContract] public interface IMySimplestService { [OperationContract] string Echo( string pInput ); }

// Host it with Juval Lowy's InProcFactory from iDesign.net like this: var myServ = InProcFactory.CreateInstance<MySimplestService, IMySimplestService>(); Console.WriteLine( myServ.Echo("Hello World") );```

// Self host it in two lines of code in a console app: ServiceHost mySimplestServiceHost = new ServiceHost(typeof(MySimplestService), new Uri("http://localhost:8008/")); mySimplestServiceHost.Open();

// Or host it on IIS.

///////////////////////////////////////////////////////////////////////////////////

It's not just that the above is possible, it's that the above is ENTERPRISE quality. You can just change a config file or attributes to change the authentication or authorization. You can add transactions. You can modify and tweak the failure modes.

I've shared your experience with going into places and having them desperate to ditch WCF. I concur with you that this is a common story.

Where you and I probably differ is that I don't see them changing to something better.

I see them having dramatically over complicated something that can be very very simple. The complexity I've seen is enough to bring NASA to it's knees. Worse, these companies don't even know they're doing it. When I show them the lines above (particularly the InProcFactory and other things from iDesign) they literally don't believe it. It can't be true because they've struggled with it for so long.

I'll admit that this is a hard problem. What we're talking about is software engineering and most people can barely program. As someone said, "Programming is easy, software development is hard."

COM and COM+ used to be difficult. Now every single class in .NET is a COM object. Most developers aren't even aware of this fact. In ServiceFabric every class is a Service. Do developers (and companies) know what to do with that power? No.

But that's not reason to throw it out because some of us do use it.

Removing the infrastructure (attributes and classes) from the code above and you have literally 4 lines of code: 1 line in the method, one in the interface definition and one to host the service with InProcFactory, and one to call the service and display the results. Other frameworks can do this in as few lines of code, but NONE of them bring the power of the entire WCF framework with them at the same time. This is the genius of WCF.

The understanding of this power is lost on almost everyone. For those of us that use it, it's heartbreaking.

On Sat, Oct 21, 2017 at 8:16 PM, Phillip Haydon notifications@github.com wrote:

I’m still yet to work for a company that isn’t desperately trying to remove all traces of EF and WCF. So sounds like core is great got me.

— 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-338447981, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo_EkwKnRkUSUdDRm9u7Hpp9Tc70qScks5surOVgaJpZM4Ikmmx .

-- Scott Hurlbert Technical Architect 415-378-9908 scotthurlbert@hotmail.com AIM: scottahurlbert Skype: hurlbert GTalk: scottahurlbert@gmail.com Blogs:

• https://medium.com/@hurlbert
• http://oknowwhatfolks.blogspot.com/
• http://agilecliches.blogspot.com/

[xprzemekw]

What features do you need in a WCF service that require .NET Core?

Guys, you are not listening at all, is this intentional?

It is not that we desperately need parts of .net core in the 'big' .net framework (4.7.1 and netstandard20 closes that gap).

We need .net core to have WCF. Name it like you want (XCF? ;D), strip it System.Web and Windows OS dependencies, make Windows OS integration optional nuget packages. We do not require it to be 100% compatible with WCF, we can take a cost of migration of whatever we have to that conceptual XCF. But for the God's sake provide service oriented framework in .net core. Because currently there is none and this is pathetic.

We need .net core to make use of docker, server nano, kestrel and all new goodies. To use .net core modularity.

[xprzemekw]

And I've seen WCF source code, it is quite modular, you do not have to rewrite anything from scratch (as someone here wrongly stated).

Or publish sources and allow community to do its work!

Now you have caged many solutions in a limbo.

[BradBarnich]

The source is available (MIT license): https://github.com/Microsoft/referencesource/tree/master/System.ServiceModel

[jan-johansson-mr]

Hi Brad,

Thanks for the link to the reference source repository! It included lots more than ServiceModel (with support for server side WCF).

Though, in the header of the source code for (e.g. UriTemplate.cs in the ServiceModel catalog), we have the header of:

//------------------------------------------------------------ // Copyright (c) Microsoft Corporation. All rights reserved. //------------------------------------------------------------

Looking through the source code in the .NET CoreFx, we have the header:

// Licensed to the .NET Foundation under one or more agreements. // The .NET Foundation licenses this file to you under the MIT license. // See the LICENSE file in the project root for more information.

Maybe this will be a problem, if working with the files from the reference source repository?

[xprzemekw]

those sources are for reference only and

a) won't build b) do not produce official output (ie in form of nuget package) c) you have no license and right to extract parts of them and build own solution

I'd like to see it as a Microsoft backed and supported project driven with community support, using github as a collaborative tool, like dotnet core, ef core, aspnet core and others producing nuget packages as an output.

[BradBarnich]

c) you have no license and right to extract parts of them and build own solution

That’s not accurate. The github sources are a subset of .net that are licensed under MIT. You can do anything you want with them. Before the Xamarin acquisition, this enabled Mono to copy some of the source to improve their implementation.

I’d like to see server support too, but that is not the current focus of this repo. I’m sure it’s a mountain of work, and priorities.

[jan-johansson-mr]

I'm not so sure about that. Each source code file clearly states that the source code is copyrighted and all rights are reserved to Microsoft (and that's okay, it's Microsoft source code). The sources have to be reissued with correct license (as in the .NET Core repository) for them to be editable and usable.

I'm all for a project on github, backed and supported by Microsoft, it's a very good solution. However, even if the source codes does not compile and so on, it'll speed up development to start from them and then by steps adapt to .NET Core. A complete re-write, with inspiration from the source code, is another magnitude of project (in my mind).

[BradBarnich]

Copyright and license are different things.

https://github.com/Microsoft/referencesource/blob/master/README.md

http://www.mono-project.com/docs/about-mono/dotnet-integration/

[abatishchev]

a) won't build

Opening the source code is not the same as opening the build infrastructure

[xprzemekw]

It's not about build infrastructure. It's about provided code and accompanying files. It won't compile because it lacks resources, some dependencies, etc. Someone above posted link to Mono site describing issues with reference source Microsoft offering. As name implies, it is for reference only and debugging.

What we need is github repo with Microsoft blessing so community could work on porting.

[SamuelCox]

Hi, not really a fan of the argumentative tone lots of commenters have taken here, but I would like to give my 2 cents. As I understand it, one of the main scenarios .Net Core is supposed to support are SOA and microservices. Not having WCF server side seems to run counter-intuitive to that. I take your point @csharpfritz that WCF is completely coupled to Windows, fair enough. But it does feel like .Net Core really needs a better story for SOA than WebAPI, if you're serious about SOA as a first class supported scenario.

[johnvndnbrk]

@SamuelCox - Well said! I took @csharpfritz's comments re WCF, WPF as statements of fact.

In the original post by @jan-johansson-mr he has list of features he likes in WCF "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"

Others contributed as well, but among these features, support for Transactions ranks high for me. I found "HangFire" and this has been a great option in this area and has other features you might find in traditional Windows Services. This is one example of ingenuity that has filled the gap left behind in .NET Core.

The purpose of this thread seems to be a discussion of what others may also see as missing features in .NET Core when leaving WCF behind. Using a stateless protocol for SOA may not be practicable. De-coupling service applications from the underlying OS so they can run on Linux, Unix, iOS, etc. may be the only acceptable way to go if .NET Core is to be positioned as supporting multiple platforms. Does it need to be stateless, though? If not, would this make a difference in bringing forward features WCF has - whether 2, 5 , 10 years old (which is not the issue)?

I am excited to move to .NET Core and have been doing so for client-side applications. REST-based services are awesome, but currently they only compliment WCF. They do not, and cannot, replace them, however.

[scotthurlbert]

You know, now that I think about it, it may be a marketing thing. Reading over the list of features that WCF has and that we all need I believe I stumbled upon a theory.

One of my arguments FOR WCF is that we get all these things in. NET standard. These features are enterprise quality features. One of the difficulties with adopting WCF is developer nativity. Often by the time they know they need it they've passed it by.

So half my theory is that even though most/all SOA apps could benefit from WCF, only a subset of those developers realize it.

The second half of my theory is that while Microsoft is slow/reluctant to build WCF into CORE they have no problem building with it on azure. I'm told that under the hood most of azure is either built on WCF or heavily inspired by it.

So the complete theory is that MS may be reluctant to give us free SO A tech to protect their cloud business. There are a ton of SOA offerings in azure on the cloud. As teams gain sophistication and outgrow CORE webclient etc, they will have little choice but to buy azure compute time.

I'm not accusing ms of being anything other than a business and to me this makes a hell of a lot more sense than some vague claim of being too closely tied to Windows (while somehow managing just fine with all of CORE).

On Nov 3, 2017 12:07 PM, "John VandenBrook" notifications@github.com wrote:

@SamuelCox https://github.com/samuelcox - Well said! I took @csharpfritz https://github.com/csharpfritz's comments re WCF, WPF as statements of fact.

In the original post by @jan-johansson-mr https://github.com/jan-johansson-mr he has list of features he likes in WCF "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"

Others contributed as well, but among these features, support for Transactions ranks high for me. I found "HangFire" and this has been a great option in this area and has other features you might find in traditional Windows Services. This is one example of ingenuity that has filled the gap left behind in .NET Core.

The purpose of this thread seems to be a discussion of what others may also see as missing features in .NET Core when leaving WCF behind. Using a stateless protocol for SOA may not be practicable. De-coupling service applications from the underlying OS so they can run on Linux, Unix, iOS, etc. may be the only acceptable way to go if .NET Core is to be positioned as supporting multiple platforms. Does it need to be stateless, though? If not, would this make a difference in bringing forward features WCF has - whether 2, 5 , 10 years old (which is not the issue)?

I am excited to move to .NET Core and have been doing so for client-side applications. REST-based services are awesome, but currently they only compliment WCF. They do not, and cannot, replace them, however.

— 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-341798766, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo_EhICK05a9RnwI_sn-Nq979nsJ-Ehks5sy2RqgaJpZM4Ikmmx .

[wasabii]

I would like to reference an issue I just opened before noticing this thread: #2378

This isn't .Net Standard. It requires the full framework. But it can fit into the ASP.Net pipeline.

[xprzemekw]

to the rescue, at least on windows? https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcing-the-windows-compatibility-pack-for-net-core/

[SamuelCox]

@xprzemekw Unless I missed something, WCF isn't in there.

[olilanz]

2 minutes into the presentation there is a slide where WCF is listed. It’s on the slide, but not yet in the compatibility pack. Remain filled with hope.

[SamuelCox]

@olilanz Ah my mistake, thanks for that.

[zhenlan]

The compat pack contains only existing WCF client packages.

[jbogard]

Outside of pulling ALL of WCF in, which is quite large, has there been any consideration given to just the pieces that don't exist easily? Like a targeted TCP API? That just does those transports, does them well, and doesn't try to build an uber-abstraction that WCF tried so very hard to do?

Most of the other stuff I'm usually only forced to use in legacy scenarios, and have moved on to better, more obvious solutions. I'm OK with isolating parts of my system that need to talk to 2005-era WS-* web services into separate, isolated pieces.

[shamusfuller]

If by transports you mean WCF handles location transparency well then yes that is correct. But, there is no uber try. WCF is an interception based execution pipeline. There's no try, only do in that aspect. you say it did/does/will not? Please say more so we may understand.

Legacy scenarios?! Other stuff? You've moved on to better? More obvious and does what WCF does?! Like what? I ask, because I know of one and only one thing that meets that description, and I would like it confirmed please.

And, what does "2005-era WS-* web services" have to do with WCF?

[darrelmiller]

The irony here is that WCF exposes services/contracts using what was supposed to be a platform/technology independent approach. Therefore anybody was supposed to be able to come along and write compatible services in any tech they wished that implemented those SOAP/WSDL/WS-* contracts. If the SOA ecosystem promised by WCF (and similar tech from other vendors) had been fulfilled then there would be no problem switching out the WCF stack for some other compliant stack.

The reality is that implementation details leaked out everywhere and the interoperability was often limited to services running the same tech stack behind the scenes. This is why the vast majority of services being built now choose plain old HTTP. Because real interoperability is possible.

It's true that HTTP doesn't provide distributed transactions, and good security is taking a long time to come to fruition, and HTTP is mostly a request/response architecture where full duplex can only be simulated.

It's also true that some folks are building distributed systems in closed/controlled ecosystems where this kind of technology coupling is manageable, and they get to take advantage of some out of the box infrastructure. But eventually there is a price to pay. In this case the price is due to the creation of a new platform that doesn't support that stack.

It's true there is no uber SOA stack in .net core, but I suspect that is largely because we have learned the lesson that one size fits all tech stacks tend to get massively over complicated.

There are many "best of breed" solutions out there that address many of the features that WCF supported. HTTP provides a substrate that allows many of these solutions to interact. Yes, there are gaps that still need to be filled. But in the future we should be able to mix and match the tools that fit the scenarios that are needed, so that never again are we faced with a giant tech stack that is an anchor for our business.

WCF is a technology that will continue to be supported for many years to come and I'm confident many companies will continue to get value from their WCF based systems, but I do believe it is time for companies to move on with new work and adopt technology that can truly achieve the interoperability goals originally promised.

[insylogo]

@darrelmiller Sounds like "throwing up your hands" to me. If .NET core doesn't support the previous .NET framework features (even when running exclusively in Windows), then it's not just a matter of "use HTTP, you'll figure out a workaround", it's a matter of "what technology stack will do what we want, and how can we decouple from a .NET ecosystem?" Adoption is going to suffer, backwards compatibility is going to be lost, and the entire vision of .NET core will go the way of Clippy.

Multiple people in this thread have had good suggestions, whether it's to enable WCF functionality on a platform-level basis (only deployable in Windows until someone implements the same distributed transaction service interface for Linux, etc.) or completely open the stack up to the community. I don't know when the heel-dragging started on this, but from now on I'm going to be investigating Metro (https://javaee.github.io/metro/) as a potential replacement for WCF for a platform-agnostic world. It's too bad, because .NET Core had so much promise.

[jbogard]

Not exactly, more “choose tools that better fit the job”. That’s what we did when we moved away from WCF....8 years ago now? The last holdout for us was "remoting" through WCF but we’ve since found a better solution.

For legacy scenarios, where we can't drop SOAP/WS-*, we just put a little API gateway in front of it so the rest of our systems can talk to it now. Works well so far!

So instead of us trying to "replace WCF" whole cloth, we found targeted, more appropriate, platform-agnostic tools for the job. When I see the list of "missing features WCF has", we've instead made intentional system design choices to eliminate the fundamental need for those features.

On Tue, Dec 12, 2017 at 10:58 AM insylogo notifications@github.com wrote:

@darrelmiller https://github.com/darrelmiller Sounds like "throwing up your hands" to me. If .NET core doesn't support the previous .NET framework features (even when running exclusively in Windows), then it's not just a matter of "use HTTP, you'll figure out a workaround", it's a matter of "what technology stack will do what we want, and how can we decouple from a .NET ecosystem?" Adoption is going to suffer, backwards compatibility is going to be lost, and the entire vision of .NET core will go the way of Clippy.

Multiple people in this thread have had good suggestions, whether it's to enable WCF functionality on a platform-level basis (only deployable in Windows until someone implements the same distributed transaction service interface for Linux, etc.) or completely open the stack up to the community. I don't know when the heel-dragging started on this, but from now on I'm going to be investigating Metro (https://javaee.github.io/ metro/) as a potential replacement for WCF for a platform-agnostic world. It's too bad, because .NET Core had so much promise.

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

[insylogo]

@jbogard Yeah, except that's pretty large corollary to "use the .NET standards you know and love with the new high performance cross-platform .NET core": be sure to plan on rewriting all your service architecture using completely different tooling.

Basically, toss the "Compatible" subheading, and add the caveat that Microsoft only intends to support their (far less popular) Azure service architectures. If you do go the distance and rewrite your whole system on different service frameworks, be sure to still run a .NET framework component to adapt older clients to the new architecture. Which means you can't actually achieve "cross platform" the same time, either. Better throw that heading out too, for anyone who has existing systems they would want to continue to support.

Here's the new tagline for .NET Core: "You won't even need WCF because this new .NET core is going to be worth re-architecting your entire software stack for".

Back in 2000 Joel Spolsky wrote something about this, I think: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[agryb]

Dear community, could somebody please advise what is the current state of server side WCF? According to the discussion above, there's no plan for implementing it in the nearest future, is that correct? Thanks!

[forki]

What parts of WCF do you need? Soap (with http basic auth) stuff is pretty easy to implement with giraffe.

Am 16.12.2017 20:44 schrieb "Alexander Gryb" notifications@github.com:

Dear community, could somebody please advise what is the current state of server side WCF? According to the discussion above, there's no plan for implementing it in the nearest future, is that correct? Thanks!

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

[agryb]

Ideally what I hope to achieve is to migrate my legacy WCF service with net tcp binding and authorization to .net core without having to switch to a different library or significantly change the code

[ccicchitelli]

I'm in the same boat, I had two big blockers before I could make my app .NET Core compatible, MEF and WCF. As of December MEF is supported, but I'm sorry to see WCF is still not currently planned.

What is the recommended replacement for a web service via System.ServiceModel that has both WCF and REST endpoints? For reference, my service methods have the following attributes to enable both WCF and REST on each method:

[OperationContract] [WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Json, UriTemplate = "GetCurrentEnergyUsage")]

Along with the end points, I'm using System.IdentityModel to validate user credentials on inbound requests.

Thanks!!

[jceddy]

This might be the wrong place to ask, but would it be possible to create a class library in an ASP.NET Core application solution that uses the full .NET Framework as long as none of the ASP.NET Core code actually references it? I mean, could I create a library that supports server-side WCF that's meant to be packaged with a set of libraries that otherwise uses .NET Core only with the knowledge that the WCF Server class library only be used by an application that runs only on Windows?

[ccicchitelli]

Wrong place indeed, but you just need to use the #if preprocessor and create a compile flag. So:

#if DESKTOP DoSomethingInDotNetFramework(); #endif

Note you'll need not just the method calls wrapped, but all of the offending code wrapped.

[wasabii]

@jceddy ASP.Net Core runs in the full framework just fine.

If you're interested in using the full framework WCF stack (HTTP-basic bindings) through ASP.Net Core, I have made something for it: https://github.com/dotnet/wcf/issues/2378

[ccicchitelli]

I finally caught up on all of the messages above, and I agree with the comments that if the .NET Core team isn't going to do this as part of .NET Core, the best path forward is to release the full WCF source code and let the community replace the pieces that are tied to Windows. It can be released as an extension to .NET Core. And I would guess for many people they can use the initial port once Windows ties are removed without waiting for many of the deeper features to be implemented.

Really the idea that .NET Core can't be used for a powerful SOA is crazy to me. In my own case I built a control system that runs on .NET Framework. Our plan to port this to .NET Core is to change from a hub and spoke architecture to a nodular architecture. Anything that runs .NET Core could be a node - but not if it cannot communicate to the other nodes in a secure and high performance manner. That's what WCF does, so let's make .NET Core equally capable with UCF (Universal Communication Foundation) or MCF (Managed Communication Foundation).

-Chris

[jbogard]

WCF is not required to make a powerful SOA. In the least.

On Sat, Jan 6, 2018 at 4:35 PM ccicchitelli notifications@github.com wrote:

I finally caught up on all of the messages above, and I agree with the comments that if the .NET Core team isn't going to do this as part of .NET Core, the best path forward is to release the full WCF source code and let the community replace the pieces that are tied to Windows. It can be released as an extension to .NET Core. And I would guess for many people they can use the initial port once Windows ties are removed without waiting for many of the deeper features to be implemented.

Really the idea that .NET Core can't be used for a powerful SOA is crazy to me. In my own case I built a control system that runs on .NET Framework. Our plan to port this to .NET Core is to change from a hub and spoke architecture to a nodular architecture. Anything that runs .NET Core could be a node - but not if it cannot communicate to the other nodes in a secure and high performance manner. That's what WCF does, so let's make .NET Core equally capable with UCF (Universal Communication Foundation) or MCF (Managed Communication Foundation).

-Chris

— 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-355783114, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGYMrXLsQ7trepxEBdW8zn7-CzAlD3Cks5tH_VCgaJpZM4Ikmmx .

[ccicchitelli]

Maybe not in C#, but with the .NET Framework it is. Unless you want to custom code tons of stuff or pull in many 3rd party libraries. Nor should we have to pull in ASP.NET Core to create even a basic HTTP web service. System.ServiceModel exists for a reason.

(Not to mention we already have the full service implemented that simply needs to be ported...)