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.

[thefringeninja]

https://www.nuget.org/packages?q=soap

cheers

[dotnetchris]

WCF and soap are entirely orthogonal. @thefringeninja for you to post that comment shows you have no idea what you're talking about and you're just trolling this serious thread.

[thefringeninja]

On the contrary, I'm being quite serious.

It seems as if there are two major use cases, based on my previous experience and reading through this issue. Feel free to correct me if you think I'm mistaken.

1) You are interoperating with Java or some other language 2) You control both ends of the wire and they are .net

Now, in the case of 1), how many people are actually using any binding other than the SOAP/HTTP binding? Would they even work? In this case I think the link I provided should be sufficient for most use cases. Also, something tells me that the MSMQ binding is never going to work on linux. Of course I would love to be proven wrong here!

In the case of 2), well, you control both ends so is wcf really necessary? As long as your code isn't tightly coupled to WCF here, it shouldn't be too much effort to write an http/json adapter for it.

[scotthurlbert]

Sure, because you want to scale manually. Handle transactions, er, um, manually? Because you want to implement auth manually. You want to implement your own context flow and header management and interception and pipeline intervention and encryption and compression and on and on...

I assure you that at the enterprise level these things are happening with wcf more than you know. One of the challenges here is that enterprise developers tend to be very silent about their efforts because what they do tends to be trade secrets. While it's common for front end teams to talk about techniques it's rare for an enterprise architect / lead to discuss how the guts of a business are wired together so you don't hear as much about it. (that's not to say they don't write, but it's much less than what's written about the web/http-this-or-that and everything in JS)

On Thu, Jun 29, 2017 at 10:55 AM, João Bragança notifications@github.com wrote:

On the contrary, I'm being quite serious.

It seems as if there are two major use cases, based on my previous experience and reading through this issue. Feel free to correct me if you think I'm mistaken.

1. You are interoperating with Java or some other language
2. You control both ends of the wire and they are .net

Now, in the case of 1), how many people are actually using any binding other than the SOAP/HTTP binding? Would they even work? In this case I think the link I provided should be sufficient for most use cases. Also, something tells me that the MSMQ binding is never going to work on linux. Of course I would love to be proven wrong here!

In the case of 2), well, you control both ends so is wcf really necessary? As long as your code isn't tightly coupled to WCF here, it shouldn't be too much effort to write an http/json adapter for it.

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

-- 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]

Sure, because you want to scale manually.

No. You can do this with about 15 lines of terraform

Handle transactions, er, um, manually?

Not sure what you mean here. Database transactions? Distributed transactions?

Because you want to implement auth manually.

Identity Server

You want to implement your own context flow and header management and interception and pipeline intervention and encryption and compression and on and on...

This and the rest of the above are trivially easy with a pipes and filters style architecture (except for compression and encryption which are baked into HTTP). Best example I can think of is OWIN.

it's rare for an enterprise architect / lead to discuss how the guts of a business are wired together so you don't hear as much about it.

Wow. That's incredibly sad.

[phillip-haydon]

@scotthurlbert can you explain these transactions because afaik you can't have transactions over http.

[alexeyzimarev]

Sure, because you want to scale manually. Handle transactions, er, um, manually? Because you want to implement auth manually. You want to implement your own context flow and header management and interception and pipeline intervention and encryption and compression and on and on...

All decent .NET messaging frameworks like MassTransit or NServiceBus perfectly handle this in much more elegant and efficient way.

[popcatalin81]

All decent .NET messaging frameworks like MassTransit or NServiceBus perfectly handle this in much more elegant and efficient way.

Yes there are a gazillion frameworks, large and small, more enterprisey or more 1337 h4x0r oriented, with different options and patterns, some rigid and some flexible ... and ... this is exactly the problem ... there's no base line.

WCF should help to get rid of all these disparate options and provide an unified and abstracted communication framework that is a base line for .Net. development.

You want binary protocolX instead of http, sure, you plug that in. You want Oauth2 instead of windows auth, sure, configure that one, you want to use NServiceBus plug in an NServiceBus binding. You want to somehow transfer contexts like a Transaction scope over the wire, you can plug that in too. The application programming model stays the same.

RPC in itself isn't a complicated thing from an .Net application point of view, you call a method or receive a call. What makes it complicated is the multitude of ways and frameworks, with security, format, feature and other options that you can implement it in.

This is where WCF should come in, and that's the point of WCF.

[abatishchev]

Yes there are a gazillion frameworks, large and small, more enterprisey or more 1337 h4x0r oriented, with different options and patterns, some rigid and some flexible ... and ... this is exactly the problem ... there's no base line. WCF should help to get rid of all these disparate options and provide an unified and abstracted communication framework that is a base line for .Net. development.

Yes there are a gazillion frameworks but we want WCF anyway. This makes no sense. Why provide arguments, pros and cons, If you just want WCF?

[scotthurlbert]

Phillip

The title of this thread is server side WCF. On the server WCF supports transactions that flow through and down through the interaction. So if your server side component wants / needs to begin a transaction and enlist other WCF services it all gets maintained and handled.

To use transactions you have to have transactional resources. Unless your company/team has done enterprise level infrastructure it's probably unlikely you have transactional resources, but none the less it is possible.

Now on the client side, you may be right. The typical http client is the browser (obviously that's a gross statement) and it's unlikely you'll start a transaction there. But if you have a .net client, even over http, you can use transactions.

Scott

On Fri, Jun 30, 2017 at 5:57 AM, Phillip Haydon notifications@github.com wrote:

@scotthurlbert https://github.com/scotthurlbert can you explain these transactions because afaik you can't have transactions over http.

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

-- 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]

Alexey,

Then you'll be making an argument for those technologies to have (at least) their client's implemented in .net core too.

Scott

On Fri, Jun 30, 2017 at 5:58 AM, Alexey Zimarev notifications@github.com wrote:

Sure, because you want to scale manually. Handle transactions, er, um, manually? Because you want to implement auth manually. You want to implement your own context flow and header management and interception and pipeline intervention and encryption and compression and on and on...

All decent .NET messaging frameworks like MassTransit or NServiceBus perfectly handle this in much more elegant and efficient way.

— 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-312260447, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo_Eqe-9NzFDOXffxnb6gBulxtF2qZgks5sJPD9gaJpZM4Ikmmx .

-- 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]

Catalin

Bravo and exactly. Let me second your comment by reminding everyone that WCF in .NET Standard requires nothing else. It's part of the framework. If you have .NET you have WCF.

This is not, in any way, an argument against any other framework. If the ones mentioned work for you then use them. But WCF is part of the .NET framework. You don't have to install it on .NET Standard.

That's what we're asking for in .NET Core.

Scott

On Fri, Jun 30, 2017 at 6:12 AM, Catalin Pop notifications@github.com wrote:

All decent .NET messaging frameworks like MassTransit or NServiceBus perfectly handle this in much more elegant and efficient way.

Yes there are a gazillion frameworks, large and small, more enterprisey or more 1337 h4x0r oriented, with different options and patterns, some rigid and some flexible ... and ... this is exactly the problem ... there's no base line.

WCF should help to get rid of all these disparate options and provide an unified and abstracted communication framework that is a base line for .Net. development.

You want binary protocolX instead of http, sure, you plug that in. You want Oauth2 instead of windows auth, sure, configure that one, you want to use NServiceBus plug in an NServiceBus binding. You want to somehow transfer contexts like a Transaction scope over the wire, you can plug that in too. The programming model stays the same.

RPC in itself is complicated thing from an .Net application point of view, you call a method or receive a call. What makes it complicated is the multitude of ways and frameworks, with security, format, feature and other options that you can implement it in.

This is where WCF should come in, and that's the point of WCF.

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

-- 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/

[miguelcastro67]

Well, I've bitten my tongue long enough here guys. Scott, I'm totally with you. I've been doing WCF for years and it is still the superior framework for enterprise level service development. The fact that some are calling it legacy is just plain wrong. Yeah, many will argue that Web API is just easier to use. Is it really? Compare apples to apples, where the client is NOT javascript (in such a case, yes to Web API) and you'll find that Web API has ALL of the same components are WCF. Physically, the only one that is missing is the service contract and that's there conceptually in the form of the resource definition. In fact, a .NET client in WCF is simpler to write than one in Web API. OK, so you need configuration. Big deal. I can't tell you how many times having that 30K foot few of the service scenario has helped me. Am I bias? Perhaps, but I also believe in #1, using the right tool for the right job, and #2, that there is no one-size-fits-all. Jeff Fritz already mentioned that it is in the plans to have it in .NET Core. I'm with most of you as I'd like to see this happen sooner rather than later, but since none of my clients are going to rush to jump to .NET Core any time soon, I'll have patience. There is a team at MS and they actively address WCF so anyone that says it's a dead product is just hung up on the shiny new coin and not on providing maximum customer value. Because the fact is that WCF is FAR more powerful than Web API. Many of you have noticed the momentum that Micro Service architecture has had. WCF can provide solutions for many of the requirements a true Micro Service implementation will have, and it can do it without third party products. Solutions for callbacks, discovery, routing, detailed fault handling, and even monitoring can be built using WCF with greater ease and power since the infrastructure for them is already built into the product. Furthermore on the topic of architecture, it pains me to see that many who look to Web API for "simplicity" do so at the sacrifice of certain architecture principles like layering, or concern separation, etc. But that is a separate argument. I have my own views on that and my own techniques and styles for achieving maximum scalability and reusability for my customer. So I know this thread started as a "server WCF on .NET core" thread, but it seemed to slightly pivot to where I thought WCF needed a little advocacy. For a while there seemed to be a rumor going around that WPF is dead and now we all see it's just been kinda rebranded since XAML is alive and well. Many seem to confuse Microsoft's lack of "pushing" or "talking" about a technology as the death of that technology. Such is not the case. So endeth the sermon.

[scotthurlbert]

[image: Inline image 1]

On Fri, Jun 30, 2017 at 10:10 AM, miguelcastro67 notifications@github.com wrote:

Well, I've bitten my tongue long enough here guys. Scott, I'm totally with you. I've been doing WCF for years and it is still the superior framework for enterprise level service development. The fact that some are calling it legacy is just plain wrong. Yeah, many will argue that Web API is just easier to use. Is it really? Compare apples to apples, where the client is NOT javascript (in such a case, yes to Web API) and you'll find that Web API has ALL of the same components are WCF. Physically, the only one that is missing is the service contract and that's there conceptually in the form of the resource definition. In fact, a .NET client in WCF is simpler to write than one in Web API. OK, so you need configuration. Big deal. I can't tell you how many times having that 30K foot few of the service scenario has helped me. Am I bias? Perhaps, but I also believe in #1 https://github.com/dotnet/wcf/issues/1, using the right tool for the right job, and #2 https://github.com/dotnet/wcf/issues/2, that there is no one-size-fits-all. Jeff Fritz already mentioned that it is in the plans to have it in .NET Core. I'm with most of you as I'd like to see this happen sooner rather than later, but since none of my clients are going to rush to jump to .NET Core any time soon, I'll have patience. There is a team at MS and they actively address WCF so anyone that says it's a dead product is just hung up on the shiny new coin and not on providing maximum customer value. Because the fact is that WCF is FAR more powerful than Web API. Many of you have noticed the momentum that Micro Service architecture has had. WCF can provide solutions for many of the requirements a true Micro Service implementation will have, and it can do it without third party products. Solutions for callbacks, discovery, routing, detailed fault handling, and even monitoring can be built using WCF with greater ease and power since the infrastructure for them is already built into the product. Furthermore on the topic of architecture, it pains me to see that many who look to Web API for "simplicity" do so at the sacrifice of certain architecture principles like layering, or concern separation, etc. But that is a separate argument. I have my own views on that and my own techniques and styles for achieving maximum scalability and reusability for my customer. So I know this thread started as a "server WCF on .NET core" thread, but it seemed to slightly pivot to where I thought WCF needed a little advocacy. For a while there seemed to be a rumor going around that WPF is dead and now we all see it's just been kinda rebranded since XAML is alive and well. Many seem to confuse Microsoft's lack of "pushing" or "talking" about a technology as the death of that technology. Such is not the case. So endeth the sermon.

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

-- 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/

[miguelcastro67]

Scott, doesn't look like an image went through

[scotthurlbert]

Cool. It was a thumbs up and thank you for your comments.

On Jul 1, 2017 12:22 PM, "miguelcastro67" notifications@github.com wrote:

Scott, doesn't look like an image went through

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

[UmairB]

I've had bad and good experiences with WCF. But the bad is not due to the technology but how it was implemented. It can be time consuming to get just right but from my exposure I can definitely see the potential and power of WCF when done right.

I'm a heavy user of asp.net core now but I would/am definitely interested in seeing how WCF is ported across to .net core. I suspect there will be compromises/changes to make since, well, the technology does start with a W! (a cross-platform transaction implementation would be interesting).

So this is a big +1 for me.

[miguelcastro67]

UmairB, might I recommend my two Pluralsight courses, WCF End-to-End and WCF Power Topics :)

[UmairB]

@miguelcastro67 Thanks! I will take a look.

Also, for an interesting exercise, see here :)

[arunsabat]

I have taken the survey. Please share the Road Map for WCF Server side support in .Net Core. That will be very helpful.

[xprzemekw]

1. Why do you need a WCF server on .NET Core?

Because we need solid SOAP Framework in .NET Core which will enable us to use plethora of new scenarios. For example docker with nanoserver (yes, servercore image is too large), for example linux. We have big SOA enabled financial system and no one will ever think of moving it to Web API for just moving it to WEB API if SOAP works perfectly for our high profile clients. That has no business value. Having no SOAP framework in .NET Core starts looking pathetic unfortunately :/

I have gut feeling that .NET Framework will lag behind .NET Core more and more in terms of new features and general progress (ie https://www.thomaslevesque.com/2017/03/29/linq-performance-improvements-in-net-core/ - I am curious when it will make its way to .NET Framewework if ever). In addition way of delivering .NET Framework upgrades is quite heavy and is system wide while for .net core it is side by side... .NET Core is way forward and not having there such crucial component won't provide you buy in from large enterprises. Do you want to have larger adoption of .net core? invest in server side wcf

If we could snap our fingers and have WCF server capabilities in .NET Core immediately, how would those capabilities change your development projects over the next 12 months?

We would start moving our solutions to .net core

[OldFriendEr]

As soon as the WCF is implemented in the .net core, i'm moving away from mono, and using net.core for our existing and future cross platform projects. Mono has so many bugs so.net core looked like a spark of hope.

[peder]

~As soon as~ if WCF is implemented. We're still waiting on more information 1.5 years later.

[Cronan]

Putting my thoughts here, WCF is essential for me to look at using .Net core, it's so disappointing that this wasn't prioritized. Having to rewrite dozens of client apps is bad enough, missing support for the server-side puts me in an impossible situation.

[insylogo]

I personally can't believe the CORE team was allowed to increment major version numbers WITHOUT WCF server-side support. It's probably the single largest bottleneck preventing companies from migrating. Hurry up!

[johnvndnbrk]

To me I see .NET Core as a huge effort to cut away from System.Web and to update immediately relevant technologies such as Entity Framework, etc. Having said that, it would still be nice to know if and what role WCF will play in future development. I was overridden on a choice to use WCF because the Manager wanted to use RESTful services and JSON. I thought at first "You are joking." I couldn't see hosting the entire application services in IIS. How would I maintain A.C.I.D. rules of data or what is to prevent IIS from recycling when I am in the middle of what would or should be a transaction.

I see both sides of the argument for turning to Web Api 2 and staying with the feature rich and mature SOAP based WCF services. These services I am referring to exist behind a firewall and are separate from any client-side frameworks, such as ASP.NET Core/MVC 5, etc. In my case, having to develop new services I did not have to concern myself with converting from WCF to Web Api 2. I was able to turn to HangFire, which was very helpful in using the best aspects of REST based services and being able to persist data in a stateless http environment.

This will not help those who are looking to upgrade from WCF to say, WCF Core, for example. There are several use cases which make using Web Api 2 sufficient, which makes using Web Api 2 not possible or not even relevant and cases in which both WCF and Web Api 2 complement each other. From what I am reading in these posts, it may not be sufficient to simply use Web Api 2 in lieu of WCF and mentioning the ease of use, etc. are not relevant in a true SOA environment. So prior to saying there is no need for WCF with Web Api 2, that may be true for some, but for most of us it is not.

For those of us who do not have the luxury of arguing to the point to our peers or Management, see if Hangfire will help you resolve some potential issues you are anticipating when moving away from WCF to Web Api. Good luck!

[Cronan]

The point I’m at, is that if I can’t use WCF, I’m going to migrate to gRPC and Protocol Buffers, and at that point I’m asking myself what I’m doing in the Microsoft stack at all anymore ...

On 19 Oct 2017, at 00:57, johnvndnbrk notifications@github.com wrote:

To me I see .NET Core as a huge effort to cut away from System.Web and to update immediately relevant technologies such as Entity Framework, etc. Having said that, it would still be nice to know if and what role WCF will play in future development. I was overridden on a choice to use WCF because the Manager wanted to use RESTful services and JSON. I thought at first "You are joking." I couldn't see hosting the entire application services in IIS. How would I maintain A.C.I.D. rules of data or what is to prevent IIS from recycling when I am in the middle of what would or should be a transaction.

I see both sides of the argument for turning to Web Api 2 and staying with the feature rich and mature SOAP based WCF services. These services I am referring to exist behind a firewall and are separate from any client-side frameworks, such as ASP.NET Core/MVC 5, etc. In my case, having to develop new services I did not have to concern myself with converting from WCF to Web Api 2. I was able to turn to HangFire, which was very helpful in using the best aspects of REST based services and being able to persist data in a stateless http environment.

This will not help those who are looking to upgrade from WCF to say, WCF Core, for example. There are several use cases which make using Web Api 2 sufficient, which makes using Web Api 2 not possible or not even relevant and cases in which both WCF and Web Api 2 complement each other. From what I am reading in these posts, it may not be sufficient to simply use Web Api 2 in lieu of WCF and mentioning the ease of use, etc. are not relevant in a true SOA environment. So prior to saying there is no need for WCF with Web Api 2, that may be true for some, but for most of us it is not.

For those of us who do not have the luxury of arguing to the point to our peers or Management, see if Hangfire will help you resolve some potential issues you are anticipating when moving away from WCF to Web Api. Good luck!

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

[abatishchev]

and at that point I’m asking myself what I’m doing in the Microsoft stack at all anymore

Are you saying that WCF is the only thing you need in Microsoft stack? You've might overlooked some things, really.

P..S. Are you threatening Microsoft and/or the community to leave if won't get WCF Core now? That's hilarious to say the least.

[scotthurlbert]

Ivan, Insylogo, and John, interesting comments.

I've noticed that the tone of the commentary has shifted decidedly in the direction you both express. When I first signed on to this list there seem to be some reluctance - perhaps a misunderstanding of the need - but as .NET Core has continued to evolve, the clear desire for enterprise quality services is growing.

Thanks for adding your voice.

On Thu, Oct 19, 2017 at 8:53 AM, Ivan Cronyn notifications@github.com wrote:

The point I’m at, is that if I can’t use WCF, I’m going to migrate to gRPC and Protocol Buffers, and at that point I’m asking myself what I’m doing in the Microsoft stack at all anymore ...

On 19 Oct 2017, at 00:57, johnvndnbrk notifications@github.com wrote:

To me I see .NET Core as a huge effort to cut away from System.Web and to update immediately relevant technologies such as Entity Framework, etc. Having said that, it would still be nice to know if and what role WCF will play in future development. I was overridden on a choice to use WCF because the Manager wanted to use RESTful services and JSON. I thought at first "You are joking." I couldn't see hosting the entire application services in IIS. How would I maintain A.C.I.D. rules of data or what is to prevent IIS from recycling when I am in the middle of what would or should be a transaction.

I see both sides of the argument for turning to Web Api 2 and staying with the feature rich and mature SOAP based WCF services. These services I am referring to exist behind a firewall and are separate from any client-side frameworks, such as ASP.NET Core/MVC 5, etc. In my case, having to develop new services I did not have to concern myself with converting from WCF to Web Api 2. I was able to turn to HangFire, which was very helpful in using the best aspects of REST based services and being able to persist data in a stateless http environment.

This will not help those who are looking to upgrade from WCF to say, WCF Core, for example. There are several use cases which make using Web Api 2 sufficient, which makes using Web Api 2 not possible or not even relevant and cases in which both WCF and Web Api 2 complement each other. From what I am reading in these posts, it may not be sufficient to simply use Web Api 2 in lieu of WCF and mentioning the ease of use, etc. are not relevant in a true SOA environment. So prior to saying there is no need for WCF with Web Api 2, that may be true for some, but for most of us it is not.

For those of us who do not have the luxury of arguing to the point to our peers or Management, see if Hangfire will help you resolve some potential issues you are anticipating when moving away from WCF to Web Api. Good luck!

— You are receiving this because you commented.

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-337952366, or mute the thread https://github.com/notifications/unsubscribe-auth/ABo_EqhTJ-REGxDwelCYrkrW_kj-dWRuks5st3BngaJpZM4Ikmmx .

-- 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/

[johnvndnbrk]

P..S. Are you threatening Microsoft and/or the community to leave if won't get WCF Core now? That's hilarious to say the least.

I don't believe Microsoft would take such a cavalier attitude to those who have needs, are using the .NET service stack for ESB or application services, and can readily choose to use other technologies out there. It can be very stressful to be faced with no real good option to move forward when you have the mandate to do so.

I would say not to count out Microsoft and their creativity in bringing together the best of what has worked for us in the past with current standards used in newer technologies. We are, however, used to using a consistent .NET framework for both client and server side technologies, even though .NET Core could be used for ASP.NET 5 web development and .NET 4.7 for ongoing support of WCF. As lowly application developers who are often seen to know less than Management or infrastructure teams, our options are often limited. In any case, I guess I don't find the humor in saying on this thread that you may need to abandon Microsoft in lieu of IBM or JAVA technologies. Enterprise applications are often made up of a mix of vendors. My hope is that Microsoft does NOT lose too many WCF/ESB services developers but at the moment, a good case can be made to turn to other technology stacks based on a company's needs.

I love Microsoft! Please keep your community updated on the progress or roadmap to what we may expect so we can make informed decisions!! Thanks!

[csharpfritz]

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

Jeff

On Fri, Oct 20, 2017 at 1:23 PM, johnvndnbrk notifications@github.com wrote:

P..S. Are you threatening Microsoft and/or the community to leave if won't get WCF Core now? That's hilarious to say the least.

I don't believe Microsoft would take such a cavalier attitude to those who have needs, are using the .NET service stack for ESB or application services, and can readily choose to use other technologies out there. It can be very stressful to be faced with no real good option to move forward when you have the mandate to do so.

I would say not to count out Microsoft and their creativity in bringing together the best of what has worked for us in the past with current standards used in newer technologies. We are, however, used to using a consistent .NET framework for both client and server side technologies, even though .NET Core could be used for ASP.NET 5 web development and .NET 4.7 for ongoing support of WCF. As lowly application developers who are often seen to know less that Management or infrastructure teams, our options are often limited. In any case, I guess I don't find the humor in saying on this thread that you may need to abandon Microsoft in lieu of IBM or JAVA technologies. Enterprise applications are often made up of a mix of vendors. My hope is that Microsoft does NOT lose too many WCF/ESB services developers but at the moment, a good case can be made to turn to other technology stacks based on a companies needs.

I love Microsoft! Please keep your community updated on the progress or roadmap to what we may expect so we can make informed decisions!! Thanks!

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

[ByronAP]

that question seems backwards

[insylogo]

@csharpfritz Linux support.

[ByronAP]

lol

[csharpfritz]

That's not a good enough answer to justify an investment to re-write a 10 year old framework that has significant coupling to the Windows platform. Linux alone is not good enough...

Jeff

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

@csharpfritz https://github.com/csharpfritz Linux support.

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

[ByronAP]

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

[scotthurlbert]

I don't want to get into a whole back and forth thing here but it's good enough for .net core.

Remember, adding linux support is adding support for dozens of platforms from dozens of vendors. I would think that after 10 years of being trapped on Windows that old framework would find it quite liberating.

On Fri, Oct 20, 2017 at 12:17 PM, Jeffrey T. Fritz <notifications@github.com

wrote:

That's not a good enough answer to justify an investment to re-write a 10 year old framework that has significant coupling to the Windows platform. Linux alone is not good enough...

Jeff

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

@csharpfritz https://github.com/csharpfritz Linux support.

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

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

-- 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/

[csharpfritz]

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.

[insylogo]

@csharpfritz I'm sure nobody said anything like that when they decided to deploy SQL server to linux, design .NET core to run on linux, decouple other system.web components from IIS, and port 99% of non-UI .NET code to core. As mentioned in dozens of replies in this thread, there is no true replacement for WCF that people can convert their WCF endpoints to in any reasonable amount of time in order to execute in .NET core.

Turns out MVC is able to make the jump, but WCF people are incapable? SQL Server can make the jump to linux, but WCF is too tightly coupled to Windows? Give me a break, you're just making excuses.

[ByronAP]

WPF and Winforms are a give in since they are EXTREMELY Windows specific. WCF while does have a lot of core Windows underpinning is in fact a viable candidate unlike the rest since a lot of those ties can be broken for Linux use.

[ByronAP]

Great point about MS SQL Server but I am sure you will get crap from him because it is a paid product where .net is not

[insylogo]

@ByronAP you can run an express edition on linux.

[ByronAP]

yes you can :-) and props to the team because it is coming along nicely and we will be re-evaluating it in the future as it is not mature enough to even remotely handle our workload but M$ will continue throwing $ at it until it is because they want in on the Linux space. Why people want to fight that on a .net component level is just silly. If we can make it work even with reduced feature set then do it IMHO.

[insylogo]

How about this Fritz, give the open source community the WCF source, we'll rewrite it for .NET Core and you can take credit for opening up a major feature to the ecosystem. Win/Win?

[ByronAP]

It might already be in the repo, will check when I have a free minute

[insylogo]

The first step to decoupling WCF from Windows would be to drop the W. Could call it CF Core ;)

[ByronAP]

UCF Universal Communications Foundation

[insylogo]

Communication Foundation*

[csharpfritz]

WCF is not a trivial framework, and is a Windows component... there are plenty of ways to continue running WCF services with Windows and we continue to invest in the .NET framework.

Other products have other business reasons to enhance their platforms. We view WCF as extremely stable, capable, and coupled to Windows.

We have always made source code available at http://sourceof.net

Jeff

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

It might already be in the repo, will check

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

[insylogo]

Nice try, 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 should now consider it "extremely deprecated" with a one-way ticket to live out the rest of its days with Clippy.