New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server side WCF #1200

Closed
jan-johansson-mr opened this Issue May 23, 2016 · 264 comments

Comments

Projects
None yet
@jan-johansson-mr

jan-johansson-mr commented May 23, 2016

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.

@zhenlan zhenlan added the discussion label May 24, 2016

@zhenlan zhenlan added this to the Future milestone May 24, 2016

@guybar

This comment has been minimized.

Show comment
Hide comment
@guybar

guybar May 25, 2016

Hi,

I too appreciate WCF, and use it a lot.
For me the most important features are:

  • Security
  • Extensibllity
  • Behaviors
  • Bindings (Especially TCP.Net)
  • Metadata Exchange
  • Instance Management
  • Reliability

I think this could really be a showstopper for .Net core, if it will not have WCF server side support.

Guy

guybar commented May 25, 2016

Hi,

I too appreciate WCF, and use it a lot.
For me the most important features are:

  • Security
  • Extensibllity
  • Behaviors
  • Bindings (Especially TCP.Net)
  • Metadata Exchange
  • Instance Management
  • Reliability

I think this could really be a showstopper for .Net core, if it will not have WCF server side support.

Guy

@menaheme

This comment has been minimized.

Show comment
Hide comment
@menaheme

menaheme May 25, 2016

Helllo,

We also use WCF extensively in our applications.
To add to the lists above we also use:

  • queued services

Menahem

menaheme commented May 25, 2016

Helllo,

We also use WCF extensively in our applications.
To add to the lists above we also use:

  • queued services

Menahem

@reifnir

This comment has been minimized.

Show comment
Hide comment
@reifnir

reifnir May 25, 2016

WCF applications on Core would be a huge boon.

The only thing I would explicitly like to add to the OP's features are all of the behavior types (not just the ones available in Service Fabric)

  • Operation Behaviors
  • Service Behaviors
  • Contract Behaviors
  • Endpoint Behaviors

I distributed transactions are a prohibitive factor, they can be thrown out the window though.

reifnir commented May 25, 2016

WCF applications on Core would be a huge boon.

The only thing I would explicitly like to add to the OP's features are all of the behavior types (not just the ones available in Service Fabric)

  • Operation Behaviors
  • Service Behaviors
  • Contract Behaviors
  • Endpoint Behaviors

I distributed transactions are a prohibitive factor, they can be thrown out the window though.

@dotnetchris

This comment has been minimized.

Show comment
Hide comment
@dotnetchris

dotnetchris May 25, 2016

Service Bus binding of WCF is absolutely amazing for building push based reactive applications

dotnetchris commented May 25, 2016

Service Bus binding of WCF is absolutely amazing for building push based reactive applications

@kscelfo

This comment has been minimized.

Show comment
Hide comment
@kscelfo

kscelfo May 26, 2016

I do consider a full WCF implementation to be a prerequisite for moving to .NET core. Without it, it will remain a variation of the .NET Framework that cannot be utilized behind the firewall of major enterprise applications that employ Service Orientation. The major features I rely on that haven't been mentioned are:

  • Net.TCP Binding
  • Net.Pipe Binding
  • Interception-based Pipeline
  • Context
  • Headers
  • Contract-based Coding Model

The two bindings are required to enable the efficiency of communication that Service Oriented systems require behind the firewall.

The interception is critical to allow architects to provide the necessary aspects of the system in a way that does not require the developers to do anything except code as they normally would.

Contexts and Headers are required to propagate information that is ubiquitous through the application’s stack from the client layer all the way down to the data layer and back up again without affecting the call contracts. Here, I’m thinking about identity information as a universal example.

The contract-based coding model is really necessary to avoid going back to the string-parsing voodoo that had us living in a type-uncertain, data-validity-in-question wild-west back when Microsoft thought passing hash tables to and from SOAP web services was a good idea.

kscelfo commented May 26, 2016

I do consider a full WCF implementation to be a prerequisite for moving to .NET core. Without it, it will remain a variation of the .NET Framework that cannot be utilized behind the firewall of major enterprise applications that employ Service Orientation. The major features I rely on that haven't been mentioned are:

  • Net.TCP Binding
  • Net.Pipe Binding
  • Interception-based Pipeline
  • Context
  • Headers
  • Contract-based Coding Model

The two bindings are required to enable the efficiency of communication that Service Oriented systems require behind the firewall.

The interception is critical to allow architects to provide the necessary aspects of the system in a way that does not require the developers to do anything except code as they normally would.

Contexts and Headers are required to propagate information that is ubiquitous through the application’s stack from the client layer all the way down to the data layer and back up again without affecting the call contracts. Here, I’m thinking about identity information as a universal example.

The contract-based coding model is really necessary to avoid going back to the string-parsing voodoo that had us living in a type-uncertain, data-validity-in-question wild-west back when Microsoft thought passing hash tables to and from SOAP web services was a good idea.

@jan-johansson-mr

This comment has been minimized.

Show comment
Hide comment
@jan-johansson-mr

jan-johansson-mr May 28, 2016

Thanks for input. The implementation of back-end systems needs a mature communication stack, such as WCF. As you pointed out in the thread, a .NET Core positioned on the client side is in my mind taking away the potential of what .NET Core can be.

I'm sure we all can wire basic communication (TCP, HTTP, ...) and then get bogged down into details about message parsing, to get some implementation of back-end on .NET Core. I'll stick my neck out and claim that WCF takes a lot of plumbing away from development (reduces waste and error prone code), letting us focus on business value. That is the reason why I enjoy WCF so much, and really would love to see support for server side WCF in .NET Core, rather sooner than later.

jan-johansson-mr commented May 28, 2016

Thanks for input. The implementation of back-end systems needs a mature communication stack, such as WCF. As you pointed out in the thread, a .NET Core positioned on the client side is in my mind taking away the potential of what .NET Core can be.

I'm sure we all can wire basic communication (TCP, HTTP, ...) and then get bogged down into details about message parsing, to get some implementation of back-end on .NET Core. I'll stick my neck out and claim that WCF takes a lot of plumbing away from development (reduces waste and error prone code), letting us focus on business value. That is the reason why I enjoy WCF so much, and really would love to see support for server side WCF in .NET Core, rather sooner than later.

@EricaMo

This comment has been minimized.

Show comment
Hide comment
@EricaMo

EricaMo Jun 1, 2016

Thanks for all the feedback on WCF Server top features! Keep it coming!

Providing WCF Server support for .NET Core is on the radar.

As you know, our current POR is to provide the WCF client-side libraries in .NET Core to enable UWP/ ASP.NET Core/.NET Core applications to call .NET Framework based WCF Services.

We are very interested to better understand your scenarios where WCF server side functionality is required.
Is this blocking your adoption .NET Core?
Do you have active projects on .NET Core for WCF Server scenarios? (We would like to partner closely with you)
Would you plan to port over your existing services or is this for needed new development?

EricaMo commented Jun 1, 2016

Thanks for all the feedback on WCF Server top features! Keep it coming!

Providing WCF Server support for .NET Core is on the radar.

As you know, our current POR is to provide the WCF client-side libraries in .NET Core to enable UWP/ ASP.NET Core/.NET Core applications to call .NET Framework based WCF Services.

We are very interested to better understand your scenarios where WCF server side functionality is required.
Is this blocking your adoption .NET Core?
Do you have active projects on .NET Core for WCF Server scenarios? (We would like to partner closely with you)
Would you plan to port over your existing services or is this for needed new development?

@olilanz

This comment has been minimized.

Show comment
Hide comment
@olilanz

olilanz Jun 1, 2016

A specific business case I have is that we have an investment management system with several million lines of code for which the server side is currently hosted on premise on MS Windows Servers at about 200 insurance companies and banks world wide. We have about 100+ service types, of which in the largest installations there are 700 to 800 concurrent service instances at play. Our product is driving important parts of the core businesses.

The expenditure on IT is huge for our customers. This is also the place where we are looking to make major improvements over the coming years. A part of that is to find alternative hosting environments. A favorable choice would be Windows Nano, or the .NET Core on Linux. For being able to adopt .NET Core (or Windows Nano) we are missing the WCF server side.

Since we are very happy with WCF as a programming model, there is no incentive to rewrite our applications other than that WCF server side is unavailable in our future hosting environments. Particular features that we use is long. But to start .NET Core adoption are, these are the important ones:

  • Self-hosting using ServiceModel.ServiceHost
  • NetTcp (half-duplex)
  • Message inspectors for instrumentation and access to SOAP headers
  • Behaviours
  • OperationContext
  • Contract based programming model

Yes. We would continue building WCF services also on .NET Core.

olilanz commented Jun 1, 2016

A specific business case I have is that we have an investment management system with several million lines of code for which the server side is currently hosted on premise on MS Windows Servers at about 200 insurance companies and banks world wide. We have about 100+ service types, of which in the largest installations there are 700 to 800 concurrent service instances at play. Our product is driving important parts of the core businesses.

The expenditure on IT is huge for our customers. This is also the place where we are looking to make major improvements over the coming years. A part of that is to find alternative hosting environments. A favorable choice would be Windows Nano, or the .NET Core on Linux. For being able to adopt .NET Core (or Windows Nano) we are missing the WCF server side.

Since we are very happy with WCF as a programming model, there is no incentive to rewrite our applications other than that WCF server side is unavailable in our future hosting environments. Particular features that we use is long. But to start .NET Core adoption are, these are the important ones:

  • Self-hosting using ServiceModel.ServiceHost
  • NetTcp (half-duplex)
  • Message inspectors for instrumentation and access to SOAP headers
  • Behaviours
  • OperationContext
  • Contract based programming model

Yes. We would continue building WCF services also on .NET Core.

@jan-johansson-mr

This comment has been minimized.

Show comment
Hide comment
@jan-johansson-mr

jan-johansson-mr Jun 1, 2016

In my case it is needed for new solutions, where WCF services can be agnostic deployed (Windows, Linux, OSX, cloud) on .NET Core.

jan-johansson-mr commented Jun 1, 2016

In my case it is needed for new solutions, where WCF services can be agnostic deployed (Windows, Linux, OSX, cloud) on .NET Core.

@niplar

This comment has been minimized.

Show comment
Hide comment
@niplar

niplar Jun 2, 2016

Over the past 6 years, in the solutions I have been involved in (in the .net area), we have always relied on WCF to handle the service layer (behind the firewall & intranet) of the solutions. Nothing out there gives us the same level of flexibility and support for different communication channels like WCF does.

I have been holding back moving to .net core for production environments for the lack of WCF support specifically. Not supporting WCF server on .net core creates a need to rewrite a lot of infrastructure code; which will probably end up mimicking the WCF programming model anyway.

The biggest solution I worked on was used by over 300 health care institutes, rewriting the server layers and functionalities is a big investment to say the least, not to mention high risk.
In fact, in that same solution we were looking at a way to unify the programming model between server and embeded devices (linux) for new products. Supporting WCF services on .net core (not just clients) could've been a really big help and cost saver as there would be no need to have 2 development teams; but in stead have a larger singularly focused team.

niplar commented Jun 2, 2016

Over the past 6 years, in the solutions I have been involved in (in the .net area), we have always relied on WCF to handle the service layer (behind the firewall & intranet) of the solutions. Nothing out there gives us the same level of flexibility and support for different communication channels like WCF does.

I have been holding back moving to .net core for production environments for the lack of WCF support specifically. Not supporting WCF server on .net core creates a need to rewrite a lot of infrastructure code; which will probably end up mimicking the WCF programming model anyway.

The biggest solution I worked on was used by over 300 health care institutes, rewriting the server layers and functionalities is a big investment to say the least, not to mention high risk.
In fact, in that same solution we were looking at a way to unify the programming model between server and embeded devices (linux) for new products. Supporting WCF services on .net core (not just clients) could've been a really big help and cost saver as there would be no need to have 2 development teams; but in stead have a larger singularly focused team.

@fefedimoraes

This comment has been minimized.

Show comment
Hide comment
@fefedimoraes

fefedimoraes Jun 2, 2016

My scenario is pretty much similar to @olilanz's, except that my business case is Point of Sales. Like him, we have our application deployed to numerous stores world wide. We are also looking for alternate ways of hosting our application in order to reduce infrastructure costs. As @jan-johansson-mr said, agnostic deploying WCF services would be great and would give us a huge flexibility.

WCF plays a major role in our application: it is based on a plug-in architecture where which plug-in is basically a WCF Service, so communication between plug-ins are actually WCF calls. Changing this aspect would mean have to rewrite/rethink a lot of infrastructure code.

In our case, self hosting using instances of ServiceHost and the Contract based programming model is crucial. Our plan is not only migrate existing services, but also create new services.

fefedimoraes commented Jun 2, 2016

My scenario is pretty much similar to @olilanz's, except that my business case is Point of Sales. Like him, we have our application deployed to numerous stores world wide. We are also looking for alternate ways of hosting our application in order to reduce infrastructure costs. As @jan-johansson-mr said, agnostic deploying WCF services would be great and would give us a huge flexibility.

WCF plays a major role in our application: it is based on a plug-in architecture where which plug-in is basically a WCF Service, so communication between plug-ins are actually WCF calls. Changing this aspect would mean have to rewrite/rethink a lot of infrastructure code.

In our case, self hosting using instances of ServiceHost and the Contract based programming model is crucial. Our plan is not only migrate existing services, but also create new services.

@Suriman

This comment has been minimized.

Show comment
Hide comment
@Suriman

Suriman Jun 7, 2016

Hi,

For us the most important features are:

  • Behaviors.
  • Bindings.
  • Transactions.
  • Headers.
  • Self-hosting.
  • Integration with WF.
  • Queued Services.
  • MEX.
  • Binary Serialization (intranet communications).
  • Callback operations.

Responding to Erica:

  1. Yes, at least it is delaying.
  2. Yes, we are migrating our application that also uses WF.
  3. For both scenarios.

Thanks!

Suriman commented Jun 7, 2016

Hi,

For us the most important features are:

  • Behaviors.
  • Bindings.
  • Transactions.
  • Headers.
  • Self-hosting.
  • Integration with WF.
  • Queued Services.
  • MEX.
  • Binary Serialization (intranet communications).
  • Callback operations.

Responding to Erica:

  1. Yes, at least it is delaying.
  2. Yes, we are migrating our application that also uses WF.
  3. For both scenarios.

Thanks!

@websitewill

This comment has been minimized.

Show comment
Hide comment
@websitewill

websitewill Jun 9, 2016

I have done a lot of projects that leverage the many aspects of WCF. Most of what I leverage in WCF (pretty much everything) is currently missing from .NET Core. Much of this missing capability would require various 3rd party libraries (or extensive custom code) to fill in the gaps and it's just not worth that level of investment when WCF already works, brilliantly. WCF is, above all else, a great productivity enhancer for my teams.

The biggest piece missing for me, currently, is the extensibility model that WCF provides.
Most of my projects leverage the capability to completely decouple cross-cutting concerns from my other components (which are light-weight WCF services). WCF provides a fantastic mechanism for doing this without the need of 3rd party Aspect Oriented Programming libraries. Developers don't know (or even care) and can focus solely on delivering the business value of the features they are concerned with.

We also leverage many other aspects of WCF such as:
named pipes, transactional queuing programming model, enforcement (not encouragement) of interface-based design, security capabilities, process isolation, error masking, I could go on.

Without WCF (or equivalent capabilities) in .NET core I would lose way too much productivity and cannot justify the switch. It would be great to have all of these powerful capabilities in a platform that can be used in any type of environment. Imagine, productivity of WCF plus cost-savings of cheaper hosting environments. That is a tremendous business value.

Thanks for tracking this issue,
Will

websitewill commented Jun 9, 2016

I have done a lot of projects that leverage the many aspects of WCF. Most of what I leverage in WCF (pretty much everything) is currently missing from .NET Core. Much of this missing capability would require various 3rd party libraries (or extensive custom code) to fill in the gaps and it's just not worth that level of investment when WCF already works, brilliantly. WCF is, above all else, a great productivity enhancer for my teams.

The biggest piece missing for me, currently, is the extensibility model that WCF provides.
Most of my projects leverage the capability to completely decouple cross-cutting concerns from my other components (which are light-weight WCF services). WCF provides a fantastic mechanism for doing this without the need of 3rd party Aspect Oriented Programming libraries. Developers don't know (or even care) and can focus solely on delivering the business value of the features they are concerned with.

We also leverage many other aspects of WCF such as:
named pipes, transactional queuing programming model, enforcement (not encouragement) of interface-based design, security capabilities, process isolation, error masking, I could go on.

Without WCF (or equivalent capabilities) in .NET core I would lose way too much productivity and cannot justify the switch. It would be great to have all of these powerful capabilities in a platform that can be used in any type of environment. Imagine, productivity of WCF plus cost-savings of cheaper hosting environments. That is a tremendous business value.

Thanks for tracking this issue,
Will

@kscelfo

This comment has been minimized.

Show comment
Hide comment
@kscelfo

kscelfo Jun 9, 2016

I agree with @websitewill as I am in that exact situation. I'd also like to point out that WCF in the full .NET Framework is done, finished, complete. If that spec were implemented to the letter in .NET Core I'd be very content and would be able to start transitioning projects.

Thanks,
Kenny

kscelfo commented Jun 9, 2016

I agree with @websitewill as I am in that exact situation. I'd also like to point out that WCF in the full .NET Framework is done, finished, complete. If that spec were implemented to the letter in .NET Core I'd be very content and would be able to start transitioning projects.

Thanks,
Kenny

@tpkurilla

This comment has been minimized.

Show comment
Hide comment
@tpkurilla

tpkurilla Jun 9, 2016

I have to throw my support for WCF in .NET Core as well.

My primary client is a fairly large, heterogeneous WAN with intermittent connectivity.

I have dreamed for years of having WCF across their entire network so that I can finally (!) have reliable transactions and durable services spanning their various generations of Linux and Windows.

The thought of bringing all of WCF's many capabilities (as enumerated in this thread) to my client's entire infrastructure would literally be a dream come true. We can spend the vast efforts we've previously put toward plumbing into the services that can streamline everything we do, and take us to the next level.

Please, please make this happen.

-Thomas

tpkurilla commented Jun 9, 2016

I have to throw my support for WCF in .NET Core as well.

My primary client is a fairly large, heterogeneous WAN with intermittent connectivity.

I have dreamed for years of having WCF across their entire network so that I can finally (!) have reliable transactions and durable services spanning their various generations of Linux and Windows.

The thought of bringing all of WCF's many capabilities (as enumerated in this thread) to my client's entire infrastructure would literally be a dream come true. We can spend the vast efforts we've previously put toward plumbing into the services that can streamline everything we do, and take us to the next level.

Please, please make this happen.

-Thomas

@paulharker

This comment has been minimized.

Show comment
Hide comment
@paulharker

paulharker Jun 9, 2016

Let me also mention the value of WCF in .NET core.

WCF gives the best capabailities across all my services. (Perhaps we need a sexier name for it) but in general, I use and wish to continue to use:

  • System.Transactions
  • Durable services
  • Named pipes
  • An extensibility model
  • Transactional Queuing
  • MEX framework (and MEX endpoint)

And when we can run these services on Linux (and eventually IOS), it allows the most solid framework

Paul

paulharker commented Jun 9, 2016

Let me also mention the value of WCF in .NET core.

WCF gives the best capabailities across all my services. (Perhaps we need a sexier name for it) but in general, I use and wish to continue to use:

  • System.Transactions
  • Durable services
  • Named pipes
  • An extensibility model
  • Transactional Queuing
  • MEX framework (and MEX endpoint)

And when we can run these services on Linux (and eventually IOS), it allows the most solid framework

Paul

@escherrer

This comment has been minimized.

Show comment
Hide comment
@escherrer

escherrer Jun 9, 2016

Having WCF on .Net core is not only desirable, it is essential. At it's current state WCF is THE most universal and mature framework to communicate between devices, and within devices using Named Pipes. Over the wire, it adheres to common standards allowing other platforms to communicate as well. But with WCF running in .Net core, the choice will be easy to make.

escherrer commented Jun 9, 2016

Having WCF on .Net core is not only desirable, it is essential. At it's current state WCF is THE most universal and mature framework to communicate between devices, and within devices using Named Pipes. Over the wire, it adheres to common standards allowing other platforms to communicate as well. But with WCF running in .Net core, the choice will be easy to make.

@holthopkins

This comment has been minimized.

Show comment
Hide comment
@holthopkins

holthopkins Jun 9, 2016

We have a strong need to run .NET/WCF on Linux, so please add this to the road map! We have invested heavily in WCF over the past decade and would hate to give up all the WCF benefits others have listed so well just because this was passed over by .NET Core. We use most features and benefit greatly from being able to customize/extend the framework to suit our needs, such as custom message broker support (alternatives to MSMQ).

holthopkins commented Jun 9, 2016

We have a strong need to run .NET/WCF on Linux, so please add this to the road map! We have invested heavily in WCF over the past decade and would hate to give up all the WCF benefits others have listed so well just because this was passed over by .NET Core. We use most features and benefit greatly from being able to customize/extend the framework to suit our needs, such as custom message broker support (alternatives to MSMQ).

@mjpandian

This comment has been minimized.

Show comment
Hide comment
@mjpandian

mjpandian Jun 9, 2016

Having WCF supported in .NET Core is a great idea and my list of key features are:

Security
Behaviors
Bindings
Instance Management
Throttling
Metadata Exchange.

mjpandian commented Jun 9, 2016

Having WCF supported in .NET Core is a great idea and my list of key features are:

Security
Behaviors
Bindings
Instance Management
Throttling
Metadata Exchange.

@billyweisberg

This comment has been minimized.

Show comment
Hide comment
@billyweisberg

billyweisberg Jun 10, 2016

Our team used WCF to build an entire SOA platform. Each service is hosted in it's own app domain that provides complete isolation for every service. This allowed us to monitor resources, per service, and unload a service and swap it out with the app hot. I know app domains are gone, but what could possibly replace wcf?

Service Bus + Net Messaging Binding
Net Pipe binding
strongly typed headers and contexts
Behaviors and interception
MEX

you have a super reliable, and extendable set of tools. wcf provides the best tools for building enterprise applications. Without it, you simply end up rebuilding it.

Bringing the power of wcf to other platforms would be huge.

Linux + sql + wcf + service bus + .net core looks good to me.

billyweisberg commented Jun 10, 2016

Our team used WCF to build an entire SOA platform. Each service is hosted in it's own app domain that provides complete isolation for every service. This allowed us to monitor resources, per service, and unload a service and swap it out with the app hot. I know app domains are gone, but what could possibly replace wcf?

Service Bus + Net Messaging Binding
Net Pipe binding
strongly typed headers and contexts
Behaviors and interception
MEX

you have a super reliable, and extendable set of tools. wcf provides the best tools for building enterprise applications. Without it, you simply end up rebuilding it.

Bringing the power of wcf to other platforms would be huge.

Linux + sql + wcf + service bus + .net core looks good to me.

@websitewill

This comment has been minimized.

Show comment
Hide comment
@websitewill

websitewill Jun 10, 2016

I'm curious. From what I understand, Azure itself is written, in large part, usIng WCF (or at least something that provides all the capabilities of WCF) behind the firewall. That being the case, why would it be excluded from .NET Core in the first place?

Seems odd to exclude such a powerful and foundational toolset.

Sent from my iPhone

On Jun 9, 2016, at 8:24 PM, Billy notifications@github.com wrote:

Our team used WCF to build an entire SOA platform. Each service is hosted in it's own app domain that provides complete isolation for every service. This allowed us to monitor resources, per service, and unload a service and swap it out with the app hot. I know app domains are gone, but what could possibly replace wcf?

Service Bus + Net Messaging Binding
Net Pipe binding
strongly typed headers and contexts
Behaviors and interception
MEX

you have a super reliable, and extendable set of tools. wcf provides the best tools for building enterprise applications. Without it, you simply end up rebuilding it.

Bringing the power of wcf to other platforms would be huge.

Linux + sql + wcf + service bus + .net core looks good to me.


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

websitewill commented Jun 10, 2016

I'm curious. From what I understand, Azure itself is written, in large part, usIng WCF (or at least something that provides all the capabilities of WCF) behind the firewall. That being the case, why would it be excluded from .NET Core in the first place?

Seems odd to exclude such a powerful and foundational toolset.

Sent from my iPhone

On Jun 9, 2016, at 8:24 PM, Billy notifications@github.com wrote:

Our team used WCF to build an entire SOA platform. Each service is hosted in it's own app domain that provides complete isolation for every service. This allowed us to monitor resources, per service, and unload a service and swap it out with the app hot. I know app domains are gone, but what could possibly replace wcf?

Service Bus + Net Messaging Binding
Net Pipe binding
strongly typed headers and contexts
Behaviors and interception
MEX

you have a super reliable, and extendable set of tools. wcf provides the best tools for building enterprise applications. Without it, you simply end up rebuilding it.

Bringing the power of wcf to other platforms would be huge.

Linux + sql + wcf + service bus + .net core looks good to me.


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

@vercruysb

This comment has been minimized.

Show comment
Hide comment
@vercruysb

vercruysb Jun 10, 2016

Another use case could be, using WCF on a gateway like device for example in home automation using linux based controllers with an ARM CPU and 512MB memory is not that uncommon. Being able to use .NET core on those types of devices and using WCF to allow creating a SOA like programming model, making use of named pipes and allowing to move around context and create reliable communication could create a whole other way of working than the current C daemons, dbus communicating way of doing things.

Using WCF could also than be used to for example let your app communicate with your WCF service in your house, for offline controlling. It would provide better integration with service bus allowing efficient communication to and from cloud based services.

Bjorn

vercruysb commented Jun 10, 2016

Another use case could be, using WCF on a gateway like device for example in home automation using linux based controllers with an ARM CPU and 512MB memory is not that uncommon. Being able to use .NET core on those types of devices and using WCF to allow creating a SOA like programming model, making use of named pipes and allowing to move around context and create reliable communication could create a whole other way of working than the current C daemons, dbus communicating way of doing things.

Using WCF could also than be used to for example let your app communicate with your WCF service in your house, for offline controlling. It would provide better integration with service bus allowing efficient communication to and from cloud based services.

Bjorn

@davojc

This comment has been minimized.

Show comment
Hide comment
@davojc

davojc Jun 10, 2016

We have quants writing server side code in Mono (they need cross platform) who were almost jumping up and down in glee with the introduction of .Net Core ... until I told them that it wouldn't support AppDomains, which they currently rely on heavily.

The look on their faces was one of despair. I have showed them a viable alternative using WCF and named pipes (to give them the isolation they desire without compromising performance). They were even more interested when I showed them that they could then scale these services across machines and across platform (if WCF services were supported on Linux)

So, this is blocking adoption of .NET Core in this scenario and we would be looking to port existing processes/services to .NET Core as well as developing new services using .NET Core.

David

davojc commented Jun 10, 2016

We have quants writing server side code in Mono (they need cross platform) who were almost jumping up and down in glee with the introduction of .Net Core ... until I told them that it wouldn't support AppDomains, which they currently rely on heavily.

The look on their faces was one of despair. I have showed them a viable alternative using WCF and named pipes (to give them the isolation they desire without compromising performance). They were even more interested when I showed them that they could then scale these services across machines and across platform (if WCF services were supported on Linux)

So, this is blocking adoption of .NET Core in this scenario and we would be looking to port existing processes/services to .NET Core as well as developing new services using .NET Core.

David

@joychak

This comment has been minimized.

Show comment
Hide comment
@joychak

joychak Jun 10, 2016

My company (one of the largest financial product company) has huge investment in Linux/Ubuntu. The windows infrastructure is relatively tiny but has tons of WCF services running for business critical applications. Running WCF on .NET Core running in Linux environment is a huge benefit in integrating with other (non-windows) services and platform consolidation point of view.

joychak commented Jun 10, 2016

My company (one of the largest financial product company) has huge investment in Linux/Ubuntu. The windows infrastructure is relatively tiny but has tons of WCF services running for business critical applications. Running WCF on .NET Core running in Linux environment is a huge benefit in integrating with other (non-windows) services and platform consolidation point of view.

@roncain

This comment has been minimized.

Show comment
Hide comment
@roncain

roncain Jun 10, 2016

Contributor

Thank you -- this is really great feedback and much appreciated. We hear you and are collating this feedback as well as reaching out to other known WCF customers. Especially useful are the specific features called out (e.g. queuing, transaction, etc.) because it allows us to prioritize and do targeted investigations.

For the record, the "missing" features of the full .NET framework's WCF were not deliberately excluded from .NET Core WCF. Rather, the initial goal was to support all the existing Windows Store WCF API's on NET Core (which are all client-facing) before tackling other mission-critical features of WCF. It might help to know that much of the work of porting WCF features involves re-implementing OS-level libraries that WCF depends on (e.g. socket layer, cryptography, etc.) to allow it to work cross-platform. So lighting up WCF features usually involves replacing OS-level libraries for each platform first. It might help to think that the "W" in WCF is no longer a given in NET Core.

This is one reason why it is so valuable to hear from you which features matter most, because it lets us investigate more deeply questions like "Which libraries are required to do feature X on Linux? OS X?, etc.". Please keep those suggestions and specific scenarios coming!

Contributor

roncain commented Jun 10, 2016

Thank you -- this is really great feedback and much appreciated. We hear you and are collating this feedback as well as reaching out to other known WCF customers. Especially useful are the specific features called out (e.g. queuing, transaction, etc.) because it allows us to prioritize and do targeted investigations.

For the record, the "missing" features of the full .NET framework's WCF were not deliberately excluded from .NET Core WCF. Rather, the initial goal was to support all the existing Windows Store WCF API's on NET Core (which are all client-facing) before tackling other mission-critical features of WCF. It might help to know that much of the work of porting WCF features involves re-implementing OS-level libraries that WCF depends on (e.g. socket layer, cryptography, etc.) to allow it to work cross-platform. So lighting up WCF features usually involves replacing OS-level libraries for each platform first. It might help to think that the "W" in WCF is no longer a given in NET Core.

This is one reason why it is so valuable to hear from you which features matter most, because it lets us investigate more deeply questions like "Which libraries are required to do feature X on Linux? OS X?, etc.". Please keep those suggestions and specific scenarios coming!

@SergeyZa

This comment has been minimized.

Show comment
Hide comment
@SergeyZa

SergeyZa Jun 10, 2016

  1.  Named pipes
    
  2.  System.Transactions
    
  3.  A transactional queuing programming model
    
  4.  Durable services
    
  5.   Extensibility model
    
  6.   MEX endpoint and MEX framework
    

SergeyZa commented Jun 10, 2016

  1.  Named pipes
    
  2.  System.Transactions
    
  3.  A transactional queuing programming model
    
  4.  Durable services
    
  5.   Extensibility model
    
  6.   MEX endpoint and MEX framework
    
@willblackie

This comment has been minimized.

Show comment
Hide comment
@willblackie

willblackie Jun 13, 2016

+1 please provide a way for me to build on WCF and host on linux

Having moved away from windows (an subsequently WCF) here are the things I miss the most and would love to have back.

#1 bindings > named pipes in particular, then tcp
#2 security > though i understand this will be difficult without a windows domain
#3 extensibility model > I like a number of others out there have done a decent amount with this to make working with WCF easier for engineers in my teams

willblackie commented Jun 13, 2016

+1 please provide a way for me to build on WCF and host on linux

Having moved away from windows (an subsequently WCF) here are the things I miss the most and would love to have back.

#1 bindings > named pipes in particular, then tcp
#2 security > though i understand this will be difficult without a windows domain
#3 extensibility model > I like a number of others out there have done a decent amount with this to make working with WCF easier for engineers in my teams

@oldkord

This comment has been minimized.

Show comment
Hide comment
@oldkord

oldkord Jun 13, 2016

All the bindings
Security
extensibility
Mex

I just agree with whatever one else is saying.

WCF is amazing

Rework the config to leverage the new config system. Json config > xml

oldkord commented Jun 13, 2016

All the bindings
Security
extensibility
Mex

I just agree with whatever one else is saying.

WCF is amazing

Rework the config to leverage the new config system. Json config > xml

@scotthurlbert

This comment has been minimized.

Show comment
Hide comment
@scotthurlbert

scotthurlbert Jun 14, 2016

I do a lot of work on the IoT. It would greatly facilitate creating cross platform systems if my lightweight WCF services could be hosted anywhere that .NET core could be hosted. As you can imagine, in IoT (and other systems) discovery is important so MEX and an extensible model. The ability to debug locally and to support named pipes between services is valuable. Really, in a nut shell as much of the WCF stack as possible - tranactions, bindings, durability, interoperability with azure and cloud based services (which often requires proper security and metadata).

scotthurlbert commented Jun 14, 2016

I do a lot of work on the IoT. It would greatly facilitate creating cross platform systems if my lightweight WCF services could be hosted anywhere that .NET core could be hosted. As you can imagine, in IoT (and other systems) discovery is important so MEX and an extensible model. The ability to debug locally and to support named pipes between services is valuable. Really, in a nut shell as much of the WCF stack as possible - tranactions, bindings, durability, interoperability with azure and cloud based services (which often requires proper security and metadata).

@joerglang

This comment has been minimized.

Show comment
Hide comment
@joerglang

joerglang Jun 15, 2016

Messaging between services is important and when doing enterprise backends, REST is not going to work. It lacks too many things like others have mentioned. So certainly Transactions, Queues Messaging, Named Pipes, Extensibility should be supported by .Net Core

So .NET Core has to provide those things in one way or another. If it is called WCF I don't care. Maybe it would be the opportunity to fix some of the weaknesses of WCF like the overy complicated configuration story and replace it with a convention based approach.

Also you should/must support other Messaging frameworks beside MSMQ or Service Bus. In general support of AMQP would be nice, including the various messaging patterns.

joerglang commented Jun 15, 2016

Messaging between services is important and when doing enterprise backends, REST is not going to work. It lacks too many things like others have mentioned. So certainly Transactions, Queues Messaging, Named Pipes, Extensibility should be supported by .Net Core

So .NET Core has to provide those things in one way or another. If it is called WCF I don't care. Maybe it would be the opportunity to fix some of the weaknesses of WCF like the overy complicated configuration story and replace it with a convention based approach.

Also you should/must support other Messaging frameworks beside MSMQ or Service Bus. In general support of AMQP would be nice, including the various messaging patterns.

@cumulusd

This comment has been minimized.

Show comment
Hide comment
@cumulusd

cumulusd Jun 15, 2016

WCF is still one of the best parts of the .NET Framework and having become part of .NET Core is essential.

Some particular aspects are:

  1.  Named pipes
    
  2.  System.Transactions
    
  3.  A transactional queuing programming model
    
  4.  Durable services
    
  5.   Extensibility model
    
  6.   MEX endpoint and MEX framework
    

cumulusd commented Jun 15, 2016

WCF is still one of the best parts of the .NET Framework and having become part of .NET Core is essential.

Some particular aspects are:

  1.  Named pipes
    
  2.  System.Transactions
    
  3.  A transactional queuing programming model
    
  4.  Durable services
    
  5.   Extensibility model
    
  6.   MEX endpoint and MEX framework
    
@dotnetchris

This comment has been minimized.

Show comment
Hide comment
@dotnetchris

dotnetchris Jun 15, 2016

@evelix 👍 at making ___CF have a simple convention over configuration baseline.

dotnetchris commented Jun 15, 2016

@evelix 👍 at making ___CF have a simple convention over configuration baseline.

@wi937c-amr

This comment has been minimized.

Show comment
Hide comment
@wi937c-amr

wi937c-amr Jun 15, 2016

WCF has been instrumental in delivering quality services that scale and deliver reliability by leveraging transactions across the wire (System.Transactions). With out support of WCF on .NET Core we would lose many of the "Free" benefits we get thru the extensive WCF interceptor chain, including logging, behaviors, and context flow.

wi937c-amr commented Jun 15, 2016

WCF has been instrumental in delivering quality services that scale and deliver reliability by leveraging transactions across the wire (System.Transactions). With out support of WCF on .NET Core we would lose many of the "Free" benefits we get thru the extensive WCF interceptor chain, including logging, behaviors, and context flow.

@dvorakpj

This comment has been minimized.

Show comment
Hide comment
@dvorakpj

dvorakpj Jun 16, 2016

Absolutely support the idea of having server-side "WCF" in .NET Core. We just finished a[nother] fairly large almost entirely server-side processing system ("the user experience is that there isn't any") Initially we went through a lot of pressure not to use Microsoft/ .NET mostly due to the relative advantages of other (open source) stacks when doing "microservices-based" solutions just as traditional web services. But the benefits of WCF such as the enforced contract-based programming model, the availability specifically of Named Pipes binding, flexibility of end points and bindings (yes, declarative approach/configurability can be an advantage), security, extensibility for utilities such as logging, were really key when the system grew and required scale and performance as well as maintainability and having really very little plumbing code. The obvious next step is proper containerization (we have been explicitly waiting for Nano Server) and in general being able to port the system to the next generation of runtime platform(s) without loosing any of the current qualities.

dvorakpj commented Jun 16, 2016

Absolutely support the idea of having server-side "WCF" in .NET Core. We just finished a[nother] fairly large almost entirely server-side processing system ("the user experience is that there isn't any") Initially we went through a lot of pressure not to use Microsoft/ .NET mostly due to the relative advantages of other (open source) stacks when doing "microservices-based" solutions just as traditional web services. But the benefits of WCF such as the enforced contract-based programming model, the availability specifically of Named Pipes binding, flexibility of end points and bindings (yes, declarative approach/configurability can be an advantage), security, extensibility for utilities such as logging, were really key when the system grew and required scale and performance as well as maintainability and having really very little plumbing code. The obvious next step is proper containerization (we have been explicitly waiting for Nano Server) and in general being able to port the system to the next generation of runtime platform(s) without loosing any of the current qualities.

@alexmarshall132

This comment has been minimized.

Show comment
Hide comment
@alexmarshall132

alexmarshall132 Jun 18, 2016

Throwing in my 2 cents here: I work in a heavily Microsoft-oriented shop, and having WCF baked into .NET Core would open up a lot of new operation for our department and our company. I and the other developers I work with would love to see this.

alexmarshall132 commented Jun 18, 2016

Throwing in my 2 cents here: I work in a heavily Microsoft-oriented shop, and having WCF baked into .NET Core would open up a lot of new operation for our department and our company. I and the other developers I work with would love to see this.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 9, 2018

What claim? How many WCF implementations outside .NET do you know?

forki commented Jan 9, 2018

What claim? How many WCF implementations outside .NET do you know?

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

For those of us who have spent any time in the enterprise it's a bit laughable to see this subject treated so flippantly by some...

Also, I don't think the Microsoft community moved on. But new people joined the community.

ccicchitelli commented Jan 9, 2018

For those of us who have spent any time in the enterprise it's a bit laughable to see this subject treated so flippantly by some...

Also, I don't think the Microsoft community moved on. But new people joined the community.

@Suriman

This comment has been minimized.

Show comment
Hide comment
@Suriman

Suriman Jan 9, 2018

Just one detail, if WCF is dead, why is the issue that has the most comments of all? 230 versus 33, which is the next. Almost 10 times

WCF is something that should be implemented in .NET Core.

Suriman commented Jan 9, 2018

Just one detail, if WCF is dead, why is the issue that has the most comments of all? 230 versus 33, which is the next. Almost 10 times

WCF is something that should be implemented in .NET Core.

@websitewill

This comment has been minimized.

Show comment
Hide comment
@websitewill

websitewill Jan 9, 2018

websitewill commented Jan 9, 2018

@damianh

This comment has been minimized.

Show comment
Hide comment
@damianh

damianh Jan 9, 2018

It not dead, it's undead.

This issue is troll bait in fairness.

WCF is not something that should be implemented in .NET Core.

damianh commented Jan 9, 2018

It not dead, it's undead.

This issue is troll bait in fairness.

WCF is not something that should be implemented in .NET Core.

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

"Then, I can change the binding to use whatever I want, without having to change my code. You presume to know of some other technology that can do that? Please share."

The fact that this doesn't exist elsewhere renders the argument about WCF being outdated moot IMHO. To say nothing of all the other benefits of WCF...

ccicchitelli commented Jan 9, 2018

"Then, I can change the binding to use whatever I want, without having to change my code. You presume to know of some other technology that can do that? Please share."

The fact that this doesn't exist elsewhere renders the argument about WCF being outdated moot IMHO. To say nothing of all the other benefits of WCF...

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 9, 2018

@surinam because this ALWAYS happens in such threads. People demanding a feature and if they don't get it people discuss if things are dead or not. But nobody actually offers their help - it's "Microsoft needs to do it", "people who don't need it, don't understand it", "you did not work in the enterprise like me" and all that stuff.

forki commented Jan 9, 2018

@surinam because this ALWAYS happens in such threads. People demanding a feature and if they don't get it people discuss if things are dead or not. But nobody actually offers their help - it's "Microsoft needs to do it", "people who don't need it, don't understand it", "you did not work in the enterprise like me" and all that stuff.

@phillip-haydon

This comment has been minimized.

Show comment
Hide comment
@phillip-haydon

phillip-haydon Jan 9, 2018

phillip-haydon commented Jan 9, 2018

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

"Basically look at WCF as .NET on steroids, NOT just web services."

This point seems lost on many.

ccicchitelli commented Jan 9, 2018

"Basically look at WCF as .NET on steroids, NOT just web services."

This point seems lost on many.

@damianh

This comment has been minimized.

Show comment
Hide comment
@damianh

damianh Jan 9, 2018

WCF is not something that should be implemented in .NET Core.

I would like to add, I don't really care. I just use WCF as a marker to avoid an org / project / product etc :)

damianh commented Jan 9, 2018

WCF is not something that should be implemented in .NET Core.

I would like to add, I don't really care. I just use WCF as a marker to avoid an org / project / product etc :)

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

"People seem to be throwing the word ‘enterprise’ around like it helps justify their need for WCF."

If the enterprise already has a WCF SOA, then it does...

ccicchitelli commented Jan 9, 2018

"People seem to be throwing the word ‘enterprise’ around like it helps justify their need for WCF."

If the enterprise already has a WCF SOA, then it does...

@damianh

This comment has been minimized.

Show comment
Hide comment
@damianh

damianh Jan 9, 2018

people discuss if things are dead or not.

Great thing about microsoft is they virtually never declare anything actually dead. They just move on, stop doing stuff and stop talking about stuff and eventually everyone "gets the message that wasn't directly said".

Except silverlight. They declared that one,.

... which became the basis of coreclr! undead :)

damianh commented Jan 9, 2018

people discuss if things are dead or not.

Great thing about microsoft is they virtually never declare anything actually dead. They just move on, stop doing stuff and stop talking about stuff and eventually everyone "gets the message that wasn't directly said".

Except silverlight. They declared that one,.

... which became the basis of coreclr! undead :)

@shamusfuller

This comment has been minimized.

Show comment
Hide comment
@shamusfuller

shamusfuller Jan 9, 2018

full-featured, singular communication stack into .NET Core so we can host
on cheaper metal and smaller devices,

@websitewill : and I will add to that I would like greater reach! I was very disappointed when I sat down years ago to write my first store app, and found out it could not work with my infrastructure, no WCF in it. Same goes for core, UWP, all of it. I can't use any of that. The whole point of those technologies being in service would be to give me the ability to extend my infrastructure across platforms, have other types of clients orchestrated by the infrastructure. This would be huge!

shamusfuller commented Jan 9, 2018

full-featured, singular communication stack into .NET Core so we can host
on cheaper metal and smaller devices,

@websitewill : and I will add to that I would like greater reach! I was very disappointed when I sat down years ago to write my first store app, and found out it could not work with my infrastructure, no WCF in it. Same goes for core, UWP, all of it. I can't use any of that. The whole point of those technologies being in service would be to give me the ability to extend my infrastructure across platforms, have other types of clients orchestrated by the infrastructure. This would be huge!

@websitewill

This comment has been minimized.

Show comment
Hide comment
@websitewill

websitewill Jan 9, 2018

websitewill commented Jan 9, 2018

@websitewill

This comment has been minimized.

Show comment
Hide comment
@websitewill

websitewill Jan 9, 2018

websitewill commented Jan 9, 2018

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

"For HTTP web services, there's a better .NET Core version of it - ASP.NET
Core. RPC? gRPC (though be super careful, RPC can break autonomy of
services). WS-*? Most of those were bad ideas (transactions, reliable
messaging etc.) and didn't actually encourage autonomy. Proxy classes?
Stopped using them, even inside WCF because it encouraged RPC-style
services. Used service channels directly instead.

TCP? System.Net.Sockets
MSMQ? Not on .NET Core since it's not xplat. But you can do Azure Service
Bus or RabbitMQ, open protocols with AMQP and client libraries that
actually match the protocols and brokers.
IPC w/ named pipes? System.IO.Pipes (or if you want, you can always do
ZeroMQ if that floats your boat)"

To me this reply is equal parts helpful and ridiculous. It's helpful because those things do what you say. It's ridiculous because it ignores that you call do all of them in WCF, WITHOUT CODE CHANGES. Want to offer a method via REST and IPC? Add a binding.

ccicchitelli commented Jan 9, 2018

"For HTTP web services, there's a better .NET Core version of it - ASP.NET
Core. RPC? gRPC (though be super careful, RPC can break autonomy of
services). WS-*? Most of those were bad ideas (transactions, reliable
messaging etc.) and didn't actually encourage autonomy. Proxy classes?
Stopped using them, even inside WCF because it encouraged RPC-style
services. Used service channels directly instead.

TCP? System.Net.Sockets
MSMQ? Not on .NET Core since it's not xplat. But you can do Azure Service
Bus or RabbitMQ, open protocols with AMQP and client libraries that
actually match the protocols and brokers.
IPC w/ named pipes? System.IO.Pipes (or if you want, you can always do
ZeroMQ if that floats your boat)"

To me this reply is equal parts helpful and ridiculous. It's helpful because those things do what you say. It's ridiculous because it ignores that you call do all of them in WCF, WITHOUT CODE CHANGES. Want to offer a method via REST and IPC? Add a binding.

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

Damianh ad hominem attacks aren't appreciated.

ccicchitelli commented Jan 9, 2018

Damianh ad hominem attacks aren't appreciated.

@websitewill

This comment has been minimized.

Show comment
Hide comment
@websitewill

websitewill Jan 9, 2018

websitewill commented Jan 9, 2018

@blowdart

This comment has been minimized.

Show comment
Hide comment
@blowdart

blowdart Jan 9, 2018

Contributor

Let's stop with commenting on people in the thread (and that includes the finger pointing that X is old and you need to move to Y) before I lock the issue because it has descended into trolling and flaming.

Contributor

blowdart commented Jan 9, 2018

Let's stop with commenting on people in the thread (and that includes the finger pointing that X is old and you need to move to Y) before I lock the issue because it has descended into trolling and flaming.

@sapiens

This comment has been minimized.

Show comment
Hide comment
@sapiens

sapiens Jan 9, 2018

I remember reading some 2-3 years ago some MS document where the recommended framework to use for new web projects was WebAPi or Asp.Net MVC. WCF was mentioned in some legacy context. Personally, I think WCF does too much for its own good. Let me choose what I need. Allow me to switch easily some component for another in my app.

sapiens commented Jan 9, 2018

I remember reading some 2-3 years ago some MS document where the recommended framework to use for new web projects was WebAPi or Asp.Net MVC. WCF was mentioned in some legacy context. Personally, I think WCF does too much for its own good. Let me choose what I need. Allow me to switch easily some component for another in my app.

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

Web API is for http services. This is not comparable in any meaningful way to the full WCF.

ccicchitelli commented Jan 9, 2018

Web API is for http services. This is not comparable in any meaningful way to the full WCF.

@websitewill

This comment has been minimized.

Show comment
Hide comment
@websitewill

websitewill Jan 9, 2018

websitewill commented Jan 9, 2018

@damianh

This comment has been minimized.

Show comment
Hide comment
@damianh

damianh Jan 9, 2018

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

damianh commented Jan 9, 2018

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

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

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

ccicchitelli commented Jan 9, 2018

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

@bwatts

This comment has been minimized.

Show comment
Hide comment
@bwatts

bwatts Jan 9, 2018

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

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

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

bwatts commented Jan 9, 2018

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

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

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

@damianh

This comment has been minimized.

Show comment
Hide comment
@damianh

damianh Jan 9, 2018

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

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

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

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

damianh commented Jan 9, 2018

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

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

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

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

@shamusfuller

This comment has been minimized.

Show comment
Hide comment
@shamusfuller

shamusfuller Jan 9, 2018

@sapiens yes!

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

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

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

shamusfuller commented Jan 9, 2018

@sapiens yes!

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

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

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

@websitewill

This comment has been minimized.

Show comment
Hide comment
@websitewill

websitewill Jan 9, 2018

websitewill commented Jan 9, 2018

@shamusfuller

This comment has been minimized.

Show comment
Hide comment
@shamusfuller

shamusfuller Jan 9, 2018

look where the puck is going.

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

shamusfuller commented Jan 9, 2018

look where the puck is going.

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

@peder peder referenced this issue Jan 9, 2018

Open

WCF Alternative #483

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

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

ccicchitelli commented Jan 9, 2018

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

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 9, 2018

@websitewill

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

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

forki commented Jan 9, 2018

@websitewill

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

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

@darrelmiller

This comment has been minimized.

Show comment
Hide comment
@darrelmiller

darrelmiller Jan 9, 2018

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

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

darrelmiller commented Jan 9, 2018

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

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

@ccicchitelli

This comment has been minimized.

Show comment
Hide comment
@ccicchitelli

ccicchitelli Jan 9, 2018

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

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

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

ccicchitelli commented Jan 9, 2018

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

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

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

@popcatalin81

This comment has been minimized.

Show comment
Hide comment
@popcatalin81

popcatalin81 Jan 9, 2018

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

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

popcatalin81 commented Jan 9, 2018

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

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

@scotthurlbert

This comment has been minimized.

Show comment
Hide comment
@scotthurlbert

scotthurlbert Jan 9, 2018

scotthurlbert commented Jan 9, 2018

@blowdart

This comment has been minimized.

Show comment
Hide comment
@blowdart

blowdart Jan 9, 2018

Contributor

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

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

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

  • Personal attacks
  • Trolling or insulting/derogatory comments

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

Contributor

blowdart commented Jan 9, 2018

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

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

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

  • Personal attacks
  • Trolling or insulting/derogatory comments

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

@blowdart blowdart closed this Jan 9, 2018

@dotnet dotnet locked as too heated and limited conversation to collaborators Jan 9, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.