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 on 25 May 2016

👍21

Helllo,

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

queued services

Menahem

menaheme on 25 May 2016

👍15

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 on 25 May 2016

👍14

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

dotnetchris on 25 May 2016

👍9

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 on 26 May 2016

👍15

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 on 28 May 2016

👍10 ❤3

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 on 1 Jun 2016

👍6 ❤3

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 on 1 Jun 2016

👍18

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 on 1 Jun 2016

👍1

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 on 2 Jun 2016

🎉2

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 on 2 Jun 2016

😄3

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 on 7 Jun 2016

👍2

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 on 9 Jun 2016

🎉3

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 on 9 Jun 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 on 9 Jun 2016

❤1

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 on 9 Jun 2016

👍3

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 on 9 Jun 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 on 9 Jun 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 on 9 Jun 2016

👍1

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 on 10 Jun 2016

❤2

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 [email protected] 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 on 10 Jun 2016

👍1

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 on 10 Jun 2016

🎉1

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 on 10 Jun 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 on 10 Jun 2016

👍1

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!

roncain on 10 Jun 2016

👍2 🎉1

Named pipes
System.Transactions
A transactional queuing programming model
Durable services
Extensibility model
MEX endpoint and MEX framework

SergeyZa on 10 Jun 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 on 13 Jun 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 on 13 Jun 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 on 14 Jun 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 on 15 Jun 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:

Named pipes
System.Transactions
A transactional queuing programming model
Durable services
Extensibility model
MEX endpoint and MEX framework

cumulusd on 15 Jun 2016

👍1

@evelix :+1: at making ___CF have a simple convention over configuration baseline.

dotnetchris on 15 Jun 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.

GrantEmpire on 15 Jun 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 on 16 Jun 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 on 18 Jun 2016

👍2

similar with mentioned above, in my case, i'm just refactoring all my app using .net core, and there're many services using wcf which called by other apps that belong to another team. my team is the first one to upgrade tech from .netframework to .netcore in my company, so the more convenient and stronger the .net core is the ealier .netcore can be used in other teams. btw, the load balance solution based on linux is considered by the operation team, after we changing to .netcore, it will be very flexible，low cost to integrate with the lb solution

vincentshow on 20 Jun 2016

While having to stacks is likely going to continue the confusion about which is recommended, I think the feedback I get from the course/talks I do is almost always about TCP connectivity. The rest of the stack is interesting, but it feels like WCF as network service versus web service to me, but I've been wrong before.

shawnwildermuth on 20 Jun 2016

We have a large SOA based healthcare application. We use WCF is two ways, internally (net.tcp and binary serialization) and externally (http and WS-*).

There are a number of RPC frameworks that could replace our use of WCF for internal service communication, but we really need WSHttpBinding support for standards based interoperability scenarios.

We exclusively use ServiceHost and configuration by code, so no loss there.

BradBarnich on 21 Jun 2016

👍2

For me, anything public facing is always WebAPI but with everything else, it is WCF simply because you have the various protocol choices via the bindings, throttling, reliable messaging etc. (so basically behind a public facing endpoint)
I kind of agree with shawnwildermuth in that having WCF may add to some confusion, but as with anything it depends on the communication and type of support introduced. If WCF has some "competing" features with what is currently available (or maybe otherwise available in a future update) thats when confusion will happen. Have the use cases/support distinct enough to circumvent this.
To summarise, yes I would want WCF server support specifically for protocol/bindings such as TCP/named pipes, as well as throttling and reliable messaging (dont care about trxs). However if it comes at the cost of mixed messages, confusion, overlapping feature set, then no thanks.

glav on 21 Jun 2016

👍4

I'm finding WCF less and less important in a world of Microservices and service bus technology.
We've been on Windows Service Bus for a while, hit too many problems, and are migrating to RabbitMQ. Our sysops guys always get a look of surprise when we tell them we don't need IIS installed.

snagify on 21 Jun 2016

👎7 👍5

There are lots of useful features about the WCF and also would be nice;
Built-in Dependency Injection (as .NET Core MVC 6)
Interceptors support
Hosting anywhere (Windows or Linux)
Working with AspNet Core Module (Without additionals configurations - httpcfg set urlacl)

gencebay on 21 Jun 2016

👍3

Please don't invest in supporting neither VB.NET nor WCF nor WWF.

abatishchev on 21 Jun 2016

👎17 👍7

Binding and security please!

rjpaulsen on 21 Jun 2016

gRPC binding would help bring familiar WCF programing model into "modren" world of microServices.

zamd on 21 Jun 2016

👍3 👎1

I don't think server side wcf is worth the investment when things like signalr and tooling should take presidence. I've always had such a hard time with wcf client Config that I dispise it :( please correct me if I'm wrong... But why wouldn't web Api be the way to go... It's lightweight and gives you everything you'd need to build apps that can work from any platform with a simple http call...

Leave security, transactions, pub/sub up to the implementer...

niemyjski on 21 Jun 2016

👎17 👍2

Something that would be really useful is full support for Owin hosting.

thefringeninja on 21 Jun 2016

I've given feedback offline on this topic, but just to keep things consolidated, I'll repeat it here :)

I've helped a couple customers adopt .NET Core who have been hung up on missing WCF features. Items which specifically have been missed include:

Service host with Http and nettcp bindings
Transactions
Discovery

mjrousos on 21 Jun 2016

👍2

Yes to standardizing the plumbing in Core to do what WCF did for .NET in pursuit of interoperability: where anything can talk to anything. From inter-process, across machines, IoT devices, to the cloud, async prcessing queues, etc. without having to reinvent the wheel with proprietary tech just to get non-functional requirements like transactions, security, reliability, etc. Give developers the tools to focus on delivering business value. Standardizing the communications framework opens possibilities for inter-connecting software systems faster than ever before. Governance and versioning of APIs will be even more critical for dependencies, perhaps dynamic proxy with roslyn and operation re-mapping. Do away with static configuration in favor of self-optimizing statistics instead (countless times where timeouts or buffer sizes caused problems during peak load). DDoS attacks can be addressed more intelligently.

Our use-cases today include native protocol bindings like net.pipe, net.tcp, msmq with transaction support via msdtc on-premise. As we migrate to Azure, off-line queuing and reliable sessions would be more critical to our system design.

alfred-c on 24 Jun 2016

👍1

Thank you for all your feedback! We have reviewed all the great responses above in regards to WCF Server support in .NET Core.

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

We would appreciate it if you can complete our survey.

.NET Core - WCF Support Survey

As well, we are looking to engage closely with the WCF Community on specific scenarios, if you are interested in this partnership - please fill out the Contact Information on the final page of the survey.

EricaMo on 16 Jul 2016

👍5

I really like youngsters telling about how fancy is using Web Api for their startups (I do too), however we also have here tons of enterprise grade software hosted on IIS and using WCF as an extremnely flexible communication stack abstracting transport layer from a developer, we do have tons of partner organization integrations using various versions of SOAP protocol. Are you telling me to code my own SOAP stack using web api or OWIN middleware? ;) I do not think so. Having no WCF Server Side support in Core makes it unusable and not even an option for consider thus effectively limiting its adoption, which I think is not MS wants. I would welcome WCF on OWIN more than warmly, then we would be having complete .NET Core offering when it comes to communicating.

xprzemekw on 19 Jul 2016

👍4

Interoperability should be implemented using open standards and lightweight technologies such as RESTfull web, micro services. XML is supported if you'd like.

Stop invest in dead technologies such as WCF and VB.NET, spending tremendous amounts of resources to nowhere, instead of spending for something good.

abatishchev on 19 Jul 2016

👎19 👍2

Leave security, transactions, pub/sub up to the implementer...

This is the worst piece of advice anyone can give. Security should never be left to the implementer, it's the source of most atrocious security bugs ever .... There are really few security experts or developers capable of implementing security details properly, this is a job for less than 1% of the programmers out there.

popcatalin81 on 21 Jul 2016

🎉4 👍2

Would love to see WCF play nicely with emerging Web Service projects that are attempting to be RMM RESTful service in addition to SOAP.

Such as, but not limited to,

APIs - OPEN API (Swagger), RAML, WADL
HATEOAS - HAL, JSON API

Would love to see MEX style endpoint that can publish these emerging technologies so we will not have to choose or implement both WebAPI and WCF.

Would love to more reliability consume this new RESTful web service that are ate least RMM Level 3 so that our team can spend more time focus on creating new process and solving problems without focusing time on the plumbing.

Looking to bridge interoperability and integration,some systems and services are now moving these emerging technology. I would love to see a clearer path to the future.

Is it possible to incorporate WebAPI in WCF in a self-hosting, Azure or docker style deployment, and have the services published as many useful technologies as an endpoint to be consumed by other services and systems?

aws-na-ss-usplu on 11 Aug 2016

👍4

Check out this project. it is not WCF, but might be useful to achieve some of backend abilities.

imatitya on 9 Sep 2016

👍1

There is another start at a WCF-like ServiceCore for .net core: https://github.com/MhAllan/TcpServiceCore

ewinnington on 4 Oct 2016

👍4

My .NET Solutions rely on configuration service behavior's for certificate authentication.
I need MEX support to generate the W.S.D.L. for smart contract binding at run-time.
We also generate service proxies at run-time from W.S.D.L. and then use reflection to load and invoke.
Also our logging via W.C.F. doesn't perform well enough unless its running using T.C.P. binding.

YulerB on 30 Nov 2016

WCF on .NET core will be critical for out migration and adoption of .NET core. We're leveraging many of the capabilities of WCF and without a clear migration path core won't be as compelling. These are requirements.

Transactions
A transactional queuing programming model
Extensibility model

jnappi on 20 Dec 2016

👍2

Another vote for WC on .net core. I have an entire infrastructure that is being converted to netstandard and core however we are currently deliberating what to do about not having WCF available. WCF for us means that developers can easily consume a complex api with almost no knowledge of it. Without WCF we will either have to abandon a lot of the plans or suffer a decrease in productivity. :-(

ByronAP on 6 Jan 2017

👍2

WCF for us means that developers can easily consume a complex api with almost no knowledge of it.

This couldn't be any better of a reason to NOT support WCF.

phillip-haydon on 12 Jan 2017

👍5 👎3

Phillip,

It's possible you misunderstood the comment. I believe the reason that
Allen made that comment (and I'd love to hear his actual reason) is that
using WCF gives you two specific things in terms of an API. First, it's
gives the true separation of dependencies and implementation (ala - the
actor model and service orientation). Second, it supports an interface
based programming model https://en.wikipedia.org/wiki/Programming_model.
By only having access to the proxy, those using the API only need to know
the proxy to use it. [Granted, that can still require a great deal of
knowledge, but not of the implementation.]

Scott

On Thu, Jan 12, 2017 at 12:22 AM, Phillip Haydon notifications@github.com
wrote:

WCF for us means that developers can easily consume a complex api with
almost no knowledge of it.

This couldn't be any better of a reason to NOT support WCF.

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 12 Jan 2017

👍2

What I mean by that is, I don't have to write a thousand page how to and hand it over for someone else to use the API. So, if I say to another dev hey the API you need for that is at this address I can basically end the conversation at that when using WCF.

Phillip, are you saying you don't like productivity? Do you not like the idea of inexperienced devs? Are you a "I am the greatest dev alive" guy? because if you even pause for a second to contemplate yes to any of those things you have a very rude awakening coming. It would also have been nice if you gave some actual reasoning behind your comment, not just flaming.

I personally have taken on the task of creating a compatible library which handles the basic WCF functionality and written the service interfaces into a shared library. While not as flexible as WCF, it is in fact a lot faster than a full implementation. My internal time to return a call is now less than 1ms (net rx to tx of simple message), which WCF can't compete with. This is all nice and dandy, however I still yearn for WCF.

ByronAP on 12 Jan 2017

👎1 👍1

Do I like being productive, absolutely. That means, never using WCF.

I think I would rather become a rice farmer than ever touch WCF again.

phillip-haydon on 13 Jan 2017

👍4 😕3 👎3

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.

This is another good reason to not support WCF. Years of people implementing designs using WCF based on false assumptions or mythical functionality.

phillip-haydon on 13 Jan 2017

😕3 👎3

I understand that WCF provides value to many, many people, but does that mean .NET Core should support it? WCF seems to be at least partially tightly-coupled to Windows--the antithesis of .NET Core. How many shops relying on WCF actually _need_ to deploy on Linux? I think that would be a bad architectural decision. If things are running so smoothly now considering the tight-coupling, why change it? Is running on Linux a net positive?

nathan-alden-sr on 13 Jan 2017

Nathan

Which parts are you talking about? There are some protocols that WCF
supports that are Windows specific but I'm not aware of WCF being windows
specific.

And yes, there is a ton of code that it would be advantageous to deploy on
Linux for the same reasons that any .NET core code should be run on Linux.

I'm surprised at the anti-WCF bias here. Where is this coming from? It
seems...in appropriate. Not all services are best built as web services
without a proxy.

Scott

On Fri, Jan 13, 2017 at 8:02 AM, Nathan Alden, Sr. <[email protected]

wrote:

I understand that WCF provides value to many, many people, but does that
mean .NET Core should support it? WCF seems to be at least partially
tightly-coupled to Windows--the antithesis of .NET Core. How many shops
relying on WCF actually need to deploy on Linux? I think that would be
a bad architectural decision. If things are running so smoothly now
considering the tight-coupling, why change it? Is running on Linux a net
positive?

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 13 Jan 2017

Seems as though, still, many folks look at WCF as "just web services" as
opposed to seeing it for what it actually is, and what lots *of people use
it for: a modern communication stack and framework for building systems.
WCF isn't just about web services - in fact, it is *very little about web
services.

On Fri, Jan 13, 2017 at 4:01 PM, Scott Hurlbert notifications@github.com
wrote:

Nathan

Which parts are you talking about? There are some protocols that WCF
supports that are Windows specific but I'm not aware of WCF being windows
specific.

And yes, there is a ton of code that it would be advantageous to deploy on
Linux for the same reasons that any .NET core code should be run on Linux.

I'm surprised at the anti-WCF bias here. Where is this coming from? It
seems...in appropriate. Not all services are best built as web services
without a proxy.

Scott

On Fri, Jan 13, 2017 at 8:02 AM, Nathan Alden, Sr. <
[email protected]

wrote:

I understand that WCF provides value to many, many people, but does that
mean .NET Core should support it? WCF seems to be at least partially
tightly-coupled to Windows--the antithesis of .NET Core. How many shops
relying on WCF actually need to deploy on Linux? I think that would be
a bad architectural decision. If things are running so smoothly now
considering the tight-coupling, why change it? Is running on Linux a net
positive?

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

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/

—
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-272546841, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ASs0gQBGc7h3H6ioD-JCh5lVB9c-tAyuks5rR-YUgaJpZM4Ikmmx
.

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

websitewill on 13 Jan 2017

Nathan: If the premise of .NET Core is to be everywhere, there ought to be a universal mechanism (WCF, or an improved successor to WCF) that connects everything together, don't you think? Why should it matter to your apps what platform your devices are running? Likewise, why should it matter how to get a message from point A to B reliably and securely, handling the serialization/deserialization, over a buffered/streamed/queued transport, supporting transactional rollback of a call chain, with fault exception propagation, etc? WCF came close to offering a universal connection mechanism with an extensible pipeline. Frameworks that do web services with REST over HTTP don't even come close.

Scott: The Windows specific part that comes to mind is distributed transaction support that relies on MSDTC. I'll leave it to the Microsofties to figure out how to NuGet and port that to non-Windows platforms.

Alfred

On Fri, Jan 13, 2017 at 1:11 PM websitewill <[email protected]notifications@github.com> wrote:
Seems as though, still, many folks look at WCF as "just web services" as

opposed to seeing it for what it actually is, and what *lots *of people use

it for: a modern communication stack and framework for building systems.

WCF isn't just about web services - in fact, it is very little about web

services.

On Fri, Jan 13, 2017 at 4:01 PM, Scott Hurlbert <[email protected]notifications@github.com>

wrote:

Nathan

>

Which parts are you talking about? There are some protocols that WCF

supports that are Windows specific but I'm not aware of WCF being windows

specific.

>

And yes, there is a ton of code that it would be advantageous to deploy on

Linux for the same reasons that any .NET core code should be run on Linux.

>

I'm surprised at the anti-WCF bias here. Where is this coming from? It

seems...in appropriate. Not all services are best built as web services

without a proxy.

>

Scott

>

On Fri, Jan 13, 2017 at 8:02 AM, Nathan Alden, Sr. <

[email protected]notifications@github.com

wrote:

>

I understand that WCF provides value to many, many people, but does that

mean .NET Core should support it? WCF seems to be at least partially

tightly-coupled to Windows--the antithesis of .NET Core. How many shops

relying on WCF actually need to deploy on Linux? I think that would be

a bad architectural decision. If things are running so smoothly now

considering the tight-coupling, why change it? Is running on Linux a net

positive?

>

—

You are receiving this because you commented.

Reply to this email directly, view it on GitHub

https://github.com/dotnet/wcf/issues/1200#issuecomment-272479021, or

mute

the thread

<https://github.com/notifications/unsubscribe-auth/ABo_

Ekz28hvIFATcjNsyv8xUh00h32U0ks5rR6AjgaJpZM4Ikmmx>

.

>

>

--

Scott Hurlbert

Technical Architect

415-378-9908 <(415)%20378-9908>

[email protected]scotthurlbert@hotmail.com

AIM: scottahurlbert

Skype: hurlbert

GTalk: [email protected]scottahurlbert@gmail.com

Blogs:

>

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/

>

—

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-272546841, or mute

the thread

https://github.com/notifications/unsubscribe-auth/ASs0gQBGc7h3H6ioD-JCh5lVB9c-tAyuks5rR-YUgaJpZM4Ikmmx

.

>

--

Will Comeaux <[email protected]websitewill@gmail.com>

LinkedIn http://www.linkedin.com/pub/wilmer-comeaux/43/14/404?trk=shareTw

Twitter https://twitter.com/wilmercomeaux

Facebook http://www.facebook.com/WilmerComeaux

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

alfred-c on 14 Jan 2017

@phillip-haydon If you don't like it, don't use it!!! Why try and stop others from using it? and most importantly why do so with absolutely no information just flaming? sorry but show me, tell me why?

I have been using WCF on some major back end infrastructure since 2013 and have never had a problem.

I am currently refactoring/rewriting a lot of WCF code to use on Linux which will use what I have dubbed UCF (Universal Communications Foundation). So far it is working great and while it is not full WCF it does use the same structuring and tags.

So, if this way of doing things is so terrible tell me why, don't just talk smack. Facts, Proof, Scientific Method... I will even take an article written by some random guy who knows nothing but javascript written on Wikipedia, just show me something.

Many companies, both large and small, use WCF! The ability to run .NET Core on Linux is huge and is being widely adopted. The idea of write once run anywhere that took off with Java is now moving to .NET. This is in part because of the language offerings of .NET (F#, C#, VB, C++...). Another big factor is the way Oracle treats the open source community (very poorly as of late) and the fact that Microsoft is doing the exact opposite by opening code not closing it off. C# is also a huge draw as it is very popular with both novice and expert programmers which allows many companies to hire lower level developers.

I personally and I am sure many others agree, that having higher developers create consumable nearly foolproof services and feeding lower level developers the basics of how it works is both a time and money saver. The only real reason I can see anyone truly hating WCF and want to see it gone is that the either; don't have much experience with it, they are a senior developer that feels like creating positions for lower levels may cause job insecurity.

I ask kindly post something informative and factual or just stop trolling.

ByronAP on 14 Jan 2017

👍2

Websitewill,

Thanks for the comment and not just because I'm part of the choir. If they
don't move WCF to .NET Core then there are a host of other things that
can't be built. Yet, if they do build it there will be little to no impact
on the dissenters. So on one hand, it's a big deal to those of us that want
it and can use it and it's of no importance to those that don't so I don't
care at all for the negative attitude.

Hopefully reason will prevail.

Scott

On Fri, Jan 13, 2017 at 1:11 PM, websitewill notifications@github.com
wrote:

Seems as though, still, many folks look at WCF as "just web services" as
opposed to seeing it for what it actually is, and what lots *of people use
it for: a modern communication stack and framework for building systems.
WCF isn't just about web services - in fact, it is *very little about web
services.

On Fri, Jan 13, 2017 at 4:01 PM, Scott Hurlbert notifications@github.com
wrote:

Nathan

Which parts are you talking about? There are some protocols that WCF
supports that are Windows specific but I'm not aware of WCF being windows
specific.

And yes, there is a ton of code that it would be advantageous to deploy
on
Linux for the same reasons that any .NET core code should be run on
Linux.

I'm surprised at the anti-WCF bias here. Where is this coming from? It
seems...in appropriate. Not all services are best built as web services
without a proxy.

Scott

On Fri, Jan 13, 2017 at 8:02 AM, Nathan Alden, Sr. <
[email protected]

wrote:

I understand that WCF provides value to many, many people, but does
that
mean .NET Core should support it? WCF seems to be at least partially
tightly-coupled to Windows--the antithesis of .NET Core. How many shops
relying on WCF actually need to deploy on Linux? I think that would
be
a bad architectural decision. If things are running so smoothly now
considering the tight-coupling, why change it? Is running on Linux a
net
positive?

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

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908> <(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/

—
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-272546841, or
mute
the thread
JCh5lVB9c-tAyuks5rR-YUgaJpZM4Ikmmx>
.

--
Will Comeaux websitewill@gmail.com
LinkedIn >
Twitter https://twitter.com/wilmercomeaux
Facebook http://www.facebook.com/WilmerComeaux

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 14 Jan 2017

👍1

Hey Alfred,

Thanks for the response. I figured it was transactions you were talking
about. You got me curious so I pulled out PWCF and scanned the
Transactions chapter.

I'm 100% sure you right about MSDTC in practice since everything until now
has been run on Windows, but my scan of the chapter suggested that WCF does
this by supporting several "transaction protocols," the distributed one
being WS-Atomic Transaction protocol (WSAT).

I take that to mean that MSDTC is behind the WSAT and that when they port
it to other platforms like .NET Core they will probably just provide the
protocol and if there are available distributed transaction mechanisms in
place to support the protocol you'll be able to use distributed
transactions, if not, it'll fall back to call&pray like normal.

Thanks for causing me to crack a book. Ha. Scott

On Fri, Jan 13, 2017 at 3:03 PM, alfred-c notifications@github.com wrote:

Nathan: If the premise of .NET Core is to be everywhere, there ought to be
a universal mechanism (WCF, or an improved successor to WCF) that connects
everything together, don't you think? Why should it matter to your apps
what platform your devices are running? Likewise, why should it matter how
to get a message from point A to B reliably and securely, handling the
serialization/deserialization, over a buffered/streamed/queued transport,
supporting transactional rollback of a call chain, with fault exception
propagation, etc? WCF came close to offering a universal connection
mechanism with an extensible pipeline. Frameworks that do web services with
REST over HTTP don't even come close.

Scott: The Windows specific part that comes to mind is distributed
transaction support that relies on MSDTC. I'll leave it to the Microsofties
to figure out how to NuGet and port that to non-Windows platforms.

Alfred

On Fri, Jan 13, 2017 at 1:11 PM websitewill <[email protected]<
mailto:[email protected]>> wrote:
Seems as though, still, many folks look at WCF as "just web services" as

opposed to seeing it for what it actually is, and what *lots *of people
use

it for: a modern communication stack and framework for building systems.

WCF isn't just about web services - in fact, it is very little about web

services.

On Fri, Jan 13, 2017 at 4:01 PM, Scott Hurlbert <[email protected]<
mailto:[email protected]>>

wrote:

Nathan

>

Which parts are you talking about? There are some protocols that WCF

supports that are Windows specific but I'm not aware of WCF being
windows

specific.

>

And yes, there is a ton of code that it would be advantageous to deploy
on

Linux for the same reasons that any .NET core code should be run on
Linux.

>

I'm surprised at the anti-WCF bias here. Where is this coming from? It

seems...in appropriate. Not all services are best built as web services

without a proxy.

>

Scott

>

On Fri, Jan 13, 2017 at 8:02 AM, Nathan Alden, Sr. <

[email protected]notifications@github.com

wrote:

>

I understand that WCF provides value to many, many people, but does
that

mean .NET Core should support it? WCF seems to be at least partially

tightly-coupled to Windows--the antithesis of .NET Core. How many
shops

relying on WCF actually need to deploy on Linux? I think that would
be

a bad architectural decision. If things are running so smoothly now

considering the tight-coupling, why change it? Is running on Linux a
net

positive?

>

—

You are receiving this because you commented.

Reply to this email directly, view it on GitHub

https://github.com/dotnet/wcf/issues/1200#issuecomment-272479021,
or

mute

the thread

<https://github.com/notifications/unsubscribe-auth/ABo_

Ekz28hvIFATcjNsyv8xUh00h32U0ks5rR6AjgaJpZM4Ikmmx>

.

>

>

>

>

--

Scott Hurlbert

Technical Architect

415-378-9908 <(415)%20378-9908> <(415)%20378-9908>

[email protected]scotthurlbert@hotmail.com

AIM: scottahurlbert

Skype: hurlbert

GTalk: [email protected]scottahurlbert@gmail.com

Blogs:

>

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/

>

—

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-272546841, or
mute

the thread

JCh5lVB9c-tAyuks5rR-YUgaJpZM4Ikmmx>

.

>

--

Will Comeaux <[email protected]websitewill@gmail.com>

LinkedIn http://www.linkedin.com/pub/wilmer-comeaux/43/14/404?trk=shareTw

Twitter https://twitter.com/wilmercomeaux

Facebook http://www.facebook.com/WilmerComeaux

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

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 14 Jan 2017

We have a customer that require a portable backend/service-solution (Linux-host) based on open source software, serving SOAP. As a .NET-shop, we see a future .NET Core WCF-service as an alternative, as we need to consider Java at this point.

cederlof on 25 Jan 2017

👍2

@cederlof I was working on my own but then I came across ServiceWire which with a very minor teak worked out well for me.

ByronAP on 25 Jan 2017

Does ServiceWire work on .NET Core? I am not seeing anything about that on
their website, but I'm not sure where to look for it. In the history it
says standard .net library.

Scott

On Wed, Jan 25, 2017 at 12:33 PM, Allen Byron Penner <
[email protected]> wrote:

@cederlof https://github.com/cederlof I was working on my own but then
I came across ServiceWire which with a very minor teak worked out well for
me.

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 25 Jan 2017

@scotthurlbert yes https://github.com/tylerjensen/ServiceWire/tree/master/src/ServiceWire.Core it is under servicewire.core pull the src, update the packages and apply my pull request and you should be up and running

ByronAP on 25 Jan 2017

or simply use my repo https://github.com/ByronAP/ServiceWire

ByronAP on 25 Jan 2017

@ByronAP thanks! However it doesn't seem like ServiceWire can _serve_ SOAP? We get WSDL-files from the customer to implement, for other clients to make calls to us using SOAP.

All the best! Cederlof

cederlof on 26 Jan 2017

The main usage scenario for our company would be using ChannelFactory to generate clients that use a SHARED(server/client) contract For communication between a web-layer (client facing) WebApi and a Backend service layer WebApi (exposed on the internal network only). There is no easy way to make a client that uses the same contracts on the server and client without a lot of boilerplate. We have tried using swagger clients, and hand coding http proxies to hit a WebApi, but there is way to much boilerplate. If you could make ChannelFactory simply work with an existing WebApi (properly using get/put/post etc) and share the contracts, I would be happy. If anyone has any other ways to do this with minimal boilerplate, I would be happy to hear how you are doing it.

psimoneau22 on 2 Mar 2017

Saying that windows based features are a blocker in moving wcf to .net core proves one saying that has little or no experience with it. In fact the only sole windows feature I can think of is automatic integration with DTC which I think is not widely used.

what else can I read there? for example some biased sayings by phillip-haydon. should we ditch swagger? it allows automatic client generation for complex web apis? just an example. looks like a troll account ;)

xprzemekw on 2 Apr 2017

Is there an official roadmap from MS on porting and supporting WCF Service or Server-side applications to dotnet core?

jarcher on 4 Apr 2017

👍7

No

ByronAP on 8 Apr 2017

👎5 😕4

I am in a situation in which I am architecting a new solution, a major aspect of which will include SOA. I cannot find anything that offers what WCF does as noted above. Also, I have read articles that WCF is dead and hear comes WebAPI (???). I didn't know they were in competition with one another. I use WebAPI on the web, client-side but behind our firewall I need a robust solution composed of services developed on our Windows application servers. Where WCF exceeds my needs, I cannot find anything to recommend to my higher ups as an alternative. I am having to persuade management that WCF is not dead, won't be a maintenance nightmare in the future when there will only be a scant few who know WCF anymore, that WebApi AND .NET Core are not replacements, etc. I wish that Microsoft would be more committed to WCF and emphasize that it will be ported or moved along with .NET Core, or a commitment to some roadmap. How they are lacking a roadmap for such a comprehensive and core technology stack, leaving room for bloggers to post "WCF is dead ... love live MVC 6" is unfortunate. I am so glad I found this thread and see so many others who find WCF invaluable. It seems that where there is mention that WCF is dead comments, you will also find comments of how hard WCF is compared to WebApi, etc. If I may, see pluralsight.com's courses on WCF by Miguel Castro, his most recent being in 2016. Cheers!

johnvndnbrk on 5 May 2017

👍7 ❤5

Good to see some love for this very alive-and-well technology. My Pluralsight courses have been very successful on this topic. My prediction is a resurgence as true micro service architectures get more mainstream. Many of the things you need to consider in properly architecting micro service systems are built into WCF. You guys all rock!

miguelcastro67 on 6 May 2017

👍2

@johnvndnbrk WCF is solid rock and mature, you won't be disappointed. However this good old Microsoft, create something and abandon.

xprzemekw on 10 May 2017

👍1

WCF has been abandoned in exactly the same way that the socket library has
been abandoned...

It has been so thoroughly tested and tuned that further development is
not needed.

What's there just works.

So, no, they don't have a WCF team anymore. But it is because it isn't
needed, not because WCF is being abandoned.

On Wed, May 10, 2017 at 3:47 AM, xprzemekw notifications@github.com wrote:

@johnvndnbrk https://github.com/johnvndnbrk WCF is solid rock and
mature, you won't be disappointed. However this good old Microsoft, create
something and abandon.

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

--
Thomas Kurilla
tpkurilla at gmail dot com

tpkurilla on 10 May 2017

Thinking about a service like LogMeIn: I need to maintain a persistent connection from clients to servers so I know they are online and can initiate a remote access from server instantly if they are online, even behind firewalls. And what about big file transfers (big, like, what FASP from Aspera can do)?

cleytonb on 11 May 2017

My company is also waiting for WCF implementation in .NET Core to start moving into .NET Core. Is there any chance that we will be informed of this feature's status?

ghost on 20 Jun 2017

👍9

Mine too. Thank you

On Jun 20, 2017 1:13 AM, "lolo267" notifications@github.com wrote:

My company is also waiting for WCF implementation in .NET Core to start
moving into .NET Core. Is there any chance that we will be informed of this
feature's status?

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

scotthurlbert on 20 Jun 2017

👍1

There very much is a WCF team, and we are working on features to ensure compatibility with Windows 10, Windows Server, and Windows Containers.

We had a very successful presentation at Build where we showed the first of our Windows Containers. Work is continuing in that space, and we plan to continue in these investments.

WCF for .NET Core is very much on our radar, and we are working with the ASP.NET Core to prioritize this work. We will share more details when they are available to broadcast publicly.

csharpfritz on 20 Jun 2017

👍4 🎉3

Sad times.

phillip-haydon on 20 Jun 2017

What does working with ASP.NET Core mean? Working on at least a subset of WCF server-side features that runs on .NET Core?

peder on 20 Jun 2017

@phillip-haydon Why sad times?

csharpfritz on 20 Jun 2017

@csharpfritz I imagine Phillip says "sad times" because he would like WCF to be already migrated to .NET Core. This view is shared by many development companies, but I must admit that the message is hopeful. :-)

Suriman on 21 Jun 2017

This insecurity we feel in our continued investment in developing with WCF is compounded by https://github.com/dotnet/designs/issues/9 which does not even mention WCF in a design document for networking in dotnet.

I know that server side WCF on core won't be here for a while due to resource allocations.

Sorry, this sounded a bit too negative.

I am looking forward to your communications about the future of WCF and dotnet's networking stack.

ewinnington on 26 Jun 2017

WCF Server is pretty much legacy at this point. I don't really see why new services would be built on top of it. However having a fairly full fidelity client is important. There are lots of existing services (I'm looking at you, Aussie Government) which are built on WCF and will not be changing any time soon. We can't build systems interfacing with these currently running on .NET Core.

ctolkien on 26 Jun 2017

👎2

Chad

I agree with your point about clients but have to take some issue with WCF
being legacy. It's legacy the way ToString() or Int32 is legacy as in it's
a part of the framework. There is no other way in the framework (and in
very few other add-in frameworks) to create transactionable, scaleable,
secureable, interface based services.

In understand that there are a lot of js / light-client consumers out
there, but there are also a lot of security violations and "leaks" because
if you put it in the client it's not secure.

This is an ENTIRE Wcf service:

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

Here is the interface:

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

Well, maybe hosting the service is hard. Nope. Here is the service hosted
and called. This is the code in it's entirety:

var myServ = InProcFactory.CreateInstance IMySimplestService>();
Console.WriteLine( myServ.Echo("Hello World") );

There's just nothing that is enterprise quality and as simple.

I think WCF has gotten a strangely bad rap because people implemented it in
unbelievably complicated ways. Believe it or not, for .net on both sides
of the wire, this is all that's needed. With the ServiceModelEx framework
from iDesign you can even build a proxy on the fly:

Binding binding = new BasicHttpBinding();
IMySimplestService proxy =
ChannelFactory.CreateChannel( binding, new
EndpointAddress( "http://localhost:8008/" ) );
proxy.Echo("Hello");

Seriously, that's 4 lines of code (out of a total 17 with the structural)
to create an enterprise service, it's proxy and make the service call.
That's not lecagy, that's productivity.

Scott

On Sun, Jun 25, 2017 at 4:22 PM, Chad T notifications@github.com wrote:

WCF Server is pretty much legacy at this point. I don't really see why new
services would be built on top of it. However having a fairly full fidelity
client is important. There are lots of existing services (I'm looking at
you, Aussie Government) which are built on WCF and will not be changing any
time soon. We can't build systems interfacing with these currently running
on .NET Core.

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 26 Jun 2017

👍9

Yes, more investments are being made into a WCF client for .NET Core.

Why do you need a WCF server on .NET Core? Investments continue to be made
in NetFx, and with every version of Windows a new version of .NET Framework
is released that continues to deliver more support for WCF with bug fixes
and enhancements.

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?

Jeff

On Sun, Jun 25, 2017 at 8:14 PM, Scott Hurlbert notifications@github.com
wrote:

Chad

I agree with your point about clients but have to take some issue with WCF
being legacy. It's legacy the way ToString() or Int32 is legacy as in it's
a part of the framework. There is no other way in the framework (and in
very few other add-in frameworks) to create transactionable, scaleable,
secureable, interface based services.

In understand that there are a lot of js / light-client consumers out
there, but there are also a lot of security violations and "leaks" because
if you put it in the client it's not secure.

This is an ENTIRE Wcf service:

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

Here is the interface:

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

Well, maybe hosting the service is hard. Nope. Here is the service hosted
and called. This is the code in it's entirety:

var myServ = InProcFactory.CreateInstance IMySimplestService>();
Console.WriteLine( myServ.Echo("Hello World") );

There's just nothing that is enterprise quality and as simple.

I think WCF has gotten a strangely bad rap because people implemented it in
unbelievably complicated ways. Believe it or not, for .net on both sides
of the wire, this is all that's needed. With the ServiceModelEx framework
from iDesign you can even build a proxy on the fly:

Binding binding = new BasicHttpBinding();
IMySimplestService proxy =
ChannelFactory.CreateChannel( binding, new
EndpointAddress( "http://localhost:8008/" ) );
proxy.Echo("Hello");

Seriously, that's 4 lines of code (out of a total 17 with the structural)
to create an enterprise service, it's proxy and make the service call.
That's not lecagy, that's productivity.

Scott

On Sun, Jun 25, 2017 at 4:22 PM, Chad T notifications@github.com wrote:

WCF Server is pretty much legacy at this point. I don't really see why
new
services would be built on top of it. However having a fairly full
fidelity
client is important. There are lots of existing services (I'm looking at
you, Aussie Government) which are built on WCF and will not be changing
any
time soon. We can't build systems interfacing with these currently
running
on .NET Core.

—
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-310935371, or
mute
the thread
EluIAn5JrAkun2NQtURAvN9WeOraks5sHuu5gaJpZM4Ikmmx>
.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/

—
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-310937927, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEy8Z-UELvo-zTHSAHRdRBId7RPafU4ks5sHvffgaJpZM4Ikmmx
.

csharpfritz on 26 Jun 2017

Good question.

Personally I do a lot of IoT projects and what I'd really like is to be
able to run server(ish) code on something small, low-power, and cheap like
a PI. In the meantime being able to run on a small linux or windows 10
stick/box would be great. Right now I have to setup a full PC (which a
full electrical penalty) to run IoT server stuff. If I had such a thing I
can guarantee I would have several private subnets around scott-hq, where
as now everything is on one because that's where the Server PC is.

That's just one example (with hundreds of different uses). I think the
notion of what's a server and what's a client went out the window with
NodeJS. I'd much rather use a .NET Core implementation everywhere that
people are putting NodeJS.

Scott

On Sun, Jun 25, 2017 at 5:32 PM, Jeffrey T. Fritz notifications@github.com
wrote:

Yes, more investments are being made into a WCF client for .NET Core.

Why do you need a WCF server on .NET Core? Investments continue to be made
in NetFx, and with every version of Windows a new version of .NET Framework
is released that continues to deliver more support for WCF with bug fixes
and enhancements.

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?

Jeff

On Sun, Jun 25, 2017 at 8:14 PM, Scott Hurlbert notifications@github.com
wrote:

Chad

I agree with your point about clients but have to take some issue with
WCF
being legacy. It's legacy the way ToString() or Int32 is legacy as in
it's
a part of the framework. There is no other way in the framework (and in
very few other add-in frameworks) to create transactionable, scaleable,
secureable, interface based services.

In understand that there are a lot of js / light-client consumers out
there, but there are also a lot of security violations and "leaks"
because
if you put it in the client it's not secure.

This is an ENTIRE Wcf service:

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

Here is the interface:

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

Well, maybe hosting the service is hard. Nope. Here is the service hosted
and called. This is the code in it's entirety:

var myServ = InProcFactory.CreateInstance IMySimplestService>();
Console.WriteLine( myServ.Echo("Hello World") );

There's just nothing that is enterprise quality and as simple.

I think WCF has gotten a strangely bad rap because people implemented it
in
unbelievably complicated ways. Believe it or not, for .net on both sides
of the wire, this is all that's needed. With the ServiceModelEx framework
from iDesign you can even build a proxy on the fly:

Binding binding = new BasicHttpBinding();
IMySimplestService proxy =
ChannelFactory.CreateChannel( binding, new
EndpointAddress( "http://localhost:8008/" ) );
proxy.Echo("Hello");

Seriously, that's 4 lines of code (out of a total 17 with the structural)
to create an enterprise service, it's proxy and make the service call.
That's not lecagy, that's productivity.

Scott

On Sun, Jun 25, 2017 at 4:22 PM, Chad T notifications@github.com
wrote:

WCF Server is pretty much legacy at this point. I don't really see why
new
services would be built on top of it. However having a fairly full
fidelity
client is important. There are lots of existing services (I'm looking
at
you, Aussie Government) which are built on WCF and will not be changing
any
time soon. We can't build systems interfacing with these currently
running
on .NET Core.

—
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-310935371, or
mute
the thread
EluIAn5JrAkun2NQtURAvN9WeOraks5sHuu5gaJpZM4Ikmmx>
.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908> <(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/

—
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-310937927, or
mute
the thread
zTHSAHRdRBId7RPafU4ks5sHvffgaJpZM4Ikmmx>

.

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 26 Jun 2017

@csharpfritz WCF should have been what gRPC is now.

A framework for remote procedure calls, that is: session and contract based, extremely fast, and easy to use, with support for duplex and streaming. The exact opposite and complement of HTTP/Rest.

If WCF is going to be another way to create/consume HTTP/Rest like services, then it is a waste.

popcatalin81 on 26 Jun 2017

👍4

Catalin Pop

I agree that gRPC seems like a fine framework. And a necessary one for
most of it's implementations because there is nothing in the basic language
framework itself. .NET on the other hand already has WCF.

These two lines of code are just a sample but what's interesting here is
that the Binding and the Endpoint schema are components:

Binding binding = new BasicHttpBinding();
IMySimplestService proxy = ChannelFactory.CreateChannel(
binding, new EndpointAddress( "http://localhost:8008/" ) );
proxy.Echo("Hello");

This is interesting because it means that by swapping those out WCF can
communicate over Http/https, UDP, TCP-IP, MSMQ, NetPipes and a bunch of
other protocols and endpoint schemes.

I understand that in the recent web many have forgotten about anything
other than HTTP, but if your app grows you may find yourself wishing you
had the ability to use the exact same code, but pointing to a queue'd
endpoint. Sadly, most other frameworks will leave you re-implementing your
system for queueing rather than just repointing it.

Not to mention transactions (also fallen out of favor - UNTIL they are
essential) and various forms of authentication and encryption and on and on.

Nothing is wrong with gRPC. If you're happy with it use it.

All the folks on this list want is the framework functionality of WCF in
.net core so that we can build solid apps with the code similar to that
built into the .net standard. In other words, in a service oriented
http/web enabled world, we see those parts of the framework as "essential."

It's not gRPC vs WCF, it's .net core with WCF.

On Mon, Jun 26, 2017 at 1:26 AM, Catalin Pop notifications@github.com
wrote:

@csharpfritz https://github.com/csharpfritz WCF should have been what
gRPC http://www.grpc.io/ is now.

A framework for remote procedure calls, that is: session and contract
based, extremely fast, and easy to use, with support for duplex and
streaming. The exact opposite and complement of HTTP/Rest.

If WCF is going to be another way to create/consume HTTP/Rest like
services, then it is a waste.

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 26 Jun 2017

❤3 👍3

@csharpfritz Answering your questions:

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

At my current company there's a lot of legacy, PHP-based, UNIX-hosted SOAP web services which need to by rewritten. WCF would be the best solution but the lack of it in ASP.NET Core will probably cause migration to JAVA instead.

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 choose .NET stack instead of JAVA...

t4rn on 28 Jun 2017

👍6

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

cheers

thefringeninja on 28 Jun 2017

👎9 👍1

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.

dotnetchris on 29 Jun 2017

👍2

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.

thefringeninja on 29 Jun 2017

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.

You are interoperating with Java or some other language

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
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 29 Jun 2017

👍2 😄1

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.

thefringeninja on 30 Jun 2017

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

phillip-haydon on 30 Jun 2017

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.

alexeyzimarev on 30 Jun 2017

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.

popcatalin81 on 30 Jun 2017

👍5

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?

abatishchev on 30 Jun 2017

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
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

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

scotthurlbert on 30 Jun 2017

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
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 30 Jun 2017

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
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

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

scotthurlbert on 30 Jun 2017

👍7

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.

miguelcastro67 on 30 Jun 2017

👍7 🎉6

[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
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 1 Jul 2017

Scott, doesn't look like an image went through

miguelcastro67 on 1 Jul 2017

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
.

scotthurlbert on 1 Jul 2017

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.

UmairB on 3 Jul 2017

👍2

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

miguelcastro67 on 3 Jul 2017

👍1

@miguelcastro67 Thanks! I will take a look.

Also, for an interesting exercise, see here :)

UmairB on 3 Jul 2017

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

arunsabat on 18 Jul 2017

👍6

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

xprzemekw on 3 Aug 2017

👍20

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.

OldFriendEr on 6 Oct 2017

👍2

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

peder on 6 Oct 2017

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.

Cronan on 9 Oct 2017

👍7 👎1

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!

insylogo on 19 Oct 2017

👍3

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!

johnvndnbrk on 19 Oct 2017

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.

Cronan on 19 Oct 2017

👍1

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.

abatishchev on 19 Oct 2017

👎2 👍1

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
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 19 Oct 2017

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!

johnvndnbrk on 20 Oct 2017

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
.

csharpfritz on 20 Oct 2017

that question seems backwards

ByronAP on 20 Oct 2017

👍1

@csharpfritz Linux support.

insylogo on 20 Oct 2017

👍1

lol

ByronAP on 20 Oct 2017

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
.

csharpfritz on 20 Oct 2017

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

ByronAP on 20 Oct 2017

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

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
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
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

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

scotthurlbert on 20 Oct 2017

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.

csharpfritz on 20 Oct 2017

@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.

insylogo on 20 Oct 2017

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 on 20 Oct 2017

👍1

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

ByronAP on 20 Oct 2017

@ByronAP you can run an express edition on linux.

insylogo on 20 Oct 2017

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.

ByronAP on 20 Oct 2017

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?

insylogo on 20 Oct 2017

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

ByronAP on 20 Oct 2017

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

insylogo on 20 Oct 2017

😄2 👍2

UCF Universal Communications Foundation

ByronAP on 20 Oct 2017

Communication Foundation*

insylogo on 20 Oct 2017

👍1

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.

csharpfritz on 20 Oct 2017

👎1

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.

insylogo on 20 Oct 2017

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

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

Jeff

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

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

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

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

csharpfritz on 20 Oct 2017

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

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

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

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

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

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

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

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

Jeff

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

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

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

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

scotthurlbert on 20 Oct 2017

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

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

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

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

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

insylogo on 20 Oct 2017

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

iskiselev on 20 Oct 2017

👍1

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

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

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

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

Alfred

On Fri, Oct 20, 2017, 12:46 PM insylogo <[email protected]notifications@github.com> wrote:

Communication Foundation*

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

alfred-c on 21 Oct 2017

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

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

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

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

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

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

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

jan-johansson-mr on 21 Oct 2017

Spot on comments from my friend Jan. Thank you.

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

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

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

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

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

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

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

WCF.

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

Scott

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

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

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

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

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

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

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

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

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 21 Oct 2017

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

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

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

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

thefringeninja on 21 Oct 2017

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

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

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

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

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

jan-johansson-mr on 21 Oct 2017

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

It could be done, certainly.

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

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

websitewill on 21 Oct 2017

Well put WebSiteWill

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

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

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

It could be done, certainly.

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

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

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

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

scotthurlbert on 21 Oct 2017

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 21 Oct 2017

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

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

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

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

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

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

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

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

Joerg

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

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

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

Jeff

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

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

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

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

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

joerglang on 21 Oct 2017

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

phillip-haydon on 22 Oct 2017

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

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

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

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

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

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

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

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

// Or host it on IIS.

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

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

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

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

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

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

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

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

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

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

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

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

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 22 Oct 2017

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

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

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

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

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

xprzemekw on 25 Oct 2017

👍1

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

Or publish sources and allow community to do its work!

Now you have caged many solutions in a limbo.

xprzemekw on 25 Oct 2017

👍1

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

BradBarnich on 25 Oct 2017

Hi Brad,

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

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

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

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

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

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

jan-johansson-mr on 25 Oct 2017

those sources are for reference only and

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

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

xprzemekw on 26 Oct 2017

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

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

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

BradBarnich on 26 Oct 2017

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

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

jan-johansson-mr on 26 Oct 2017

Copyright and license are different things.

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

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

BradBarnich on 26 Oct 2017

a) won't build

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

abatishchev on 26 Oct 2017

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

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

xprzemekw on 27 Oct 2017

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

SamuelCox on 3 Nov 2017

👍2

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

In the original post by @jan-johansson-mr he has list of features he likes in WCF
"Here is a list of some of the WCF features (that comes to my mind):

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

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

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

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

johnvndnbrk on 3 Nov 2017

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

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

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

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

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

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

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

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

In the original post by @jan-johansson-mr
https://github.com/jan-johansson-mr he has list of features he likes in
WCF
"Here is a list of some of the WCF features (that comes to my mind):

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

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

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

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

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

scotthurlbert on 3 Nov 2017

👍1

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

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

wasabii on 13 Nov 2017

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

xprzemekw on 17 Nov 2017

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

SamuelCox on 17 Nov 2017

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

olilanz on 17 Nov 2017

@olilanz Ah my mistake, thanks for that.

SamuelCox on 17 Nov 2017

The compat pack contains only existing WCF client packages.

zhenlan on 17 Nov 2017

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

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

jbogard on 19 Nov 2017

👍6 👎1

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

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

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

shamusfuller on 21 Nov 2017

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

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

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

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

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

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

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

darrelmiller on 21 Nov 2017

👍6 👎1

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

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

insylogo on 12 Dec 2017

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

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

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

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

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

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

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

jbogard on 12 Dec 2017

👍2

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

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

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

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

insylogo on 13 Dec 2017

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

agryb on 16 Dec 2017

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

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

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

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

forki on 16 Dec 2017

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

agryb on 16 Dec 2017

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

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

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

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

Thanks!!

ccicchitelli on 5 Jan 2018

👍1

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

jceddy on 6 Jan 2018

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

#if DESKTOP
DoSomethingInDotNetFramework();
#endif

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

ccicchitelli on 6 Jan 2018

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

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

wasabii on 6 Jan 2018

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

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

-Chris

ccicchitelli on 6 Jan 2018

👍1

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

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

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

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

-Chris

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

jbogard on 7 Jan 2018

👎4 👍4

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

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

ccicchitelli on 7 Jan 2018

👍2

Actually I agree with @jbogard. I go back on my previous comment on the issue, I had no idea about the options for SOA and microservices in .NET core, but now I do, so I'm not bothered about WCF now.

SamuelCox on 7 Jan 2018

👎1 👍1

"Actually I agree with @jbogard. I go back on my previous comment on the issue, I had no idea about the options for SOA and microservices in .NET core, but now I do, so I'm not bothered about WCF now."

Care to share with us what you found for options?

ccicchitelli on 7 Jan 2018

@ccicchitelli Depends on what exact kind of architecture you want to take. Personally my preferred microservices architecture for .NET core, is self contained console apps (or windows services if you want to take a dependency on windows) that communicate via an Enterprise Service Bus. Seems the most loosely coupled option.

But, you don't have to do that via an enterprise service bus, you could equally do it via RPC, or even just make each microservice a REST endpoint. Admittedly, making them REST endpoints I wouldn't advise, as your applications become a bit more coupled to your microservices at that point, but it is still an option.

There's also a wealth of options if you're willing to use Azure, such as Service Fabric, which is clearly really powerful, but obviously not great that you're forced to use Azure. There's also Orleans and Akka.Net

Obviously, most of these options do involve taking a third party dependency, but typically not many, just a couple. Certainly it doesn't require a lot of custom code though.

SamuelCox on 7 Jan 2018

Those options you list aren't in the .NET Framework...

ccicchitelli on 7 Jan 2018

@ccicchitelli Some of them are, some of them aren't. Certainly REST is. All of them are options .net code can make use of though, so what does it matter? Embrace OSS .Net! :D

SamuelCox on 7 Jan 2018

Fundamentally Microsoft needs to ask what they expect for .NET Core if they aren't going to natively support enterprise-level SOA tooling like they do in the desktop framework.

Because I'll tell them right now, they will lose to NodeJS if they haven't already... If I was starting over building microservices at this point .NET Core wouldn't even be a consideration and it would be all Node. That's where the community is - Microsoft has no choice but to support it IMHO.

ccicchitelli on 7 Jan 2018

@ccicchitelli I disagree entirely, but each to their own.

SamuelCox on 7 Jan 2018

If I have to rely on the community I don't really think it's debatable which has the stronger tooling for SOA. It's not .NET Core. My day job is replacing the entire SOA for a Fortune 50 with Node, so...

The beauty of .NET, the reason it exists at all and why it is so popular in the enterprise, is because it has not only everything built in, but supported by all the weight of Microsoft.

If they aren't willing to do that for .NET Core I agree it's a business decision to prioritize Windows and Azure, but know that those of who are building cross platform SOA will go with Node or something else in droves.

ccicchitelli on 7 Jan 2018

Ok now I'm curious. What SOA stuff can you do with node that you can't with asp.net core?

forki on 7 Jan 2018

I think the better question is, what can you do with WCF that you can't do with ASP.NET Core (and again, why are we in ASP-land? We're not trying to serve client apps..). Dotnetchris mentions it here.

ccicchitelli on 7 Jan 2018

😕1

@ccicchitelli That's not really answering @Forki 's question. From what I know of NodeJs, everything you can do in node without a third party lib is exactly the same as what you can do in asp.net core without a lib.

SamuelCox on 7 Jan 2018

"everything you can do in node without a third party lib is exactly the same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party, I'm going to pick the one with the larger and more active community, with the larger corporate backing. Right now that's Node and JS, not .NET Core and C#.

WCF enables best-in-class SOA. It's incredibly powerful. It's just a matter of whether that will be forever tied to Windows and Azure, or be set free.

ccicchitelli on 7 Jan 2018

Agreed - "WCF enables best-in-class SOA. It's incredibly powerful."

The purpose of this list was to gauge interest.

Other peopel's lack of interest or ability to "do it another way using none
.NET libraries" in any way addresses the question that was asked and the
reasons for our responses.

Also, the purpose of this was not to educate each other on SOA and all of
the thousands of ways it can be achieved. The question was put out "Should
WCF be added to .NET core."

If I'm trying to get a team to use WCF, the single biggest selling point I
have is that it's part of the .NET framework. Why? Because I'm an
experienced guy and most of the audience is managers, PMs, junior
developers, developers, or junior architects. There are maybe 2 or 3
people on any given team that understand anything about SO. The reason
they have guys "like us" on the team is to make quality recommendations and
using what's right in front of you that is industrial strength, proven, and
enterprise ready is a pretty good thing to suggest.

Can SO be done on .NET in other ways? No one here is asking that question
(or at least that's not the purpose of this thread).

On Sun, Jan 7, 2018 at 11:34 AM, ccicchitelli notifications@github.com
wrote:

"everything you can do in node without a third party lib is exactly the
same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party, I'm going to
pick the one with the larger and more active community, with the larger
corporate backing. Right now that's Node and JS, not .NET Core and C#.

WCF enables best-in-class SOA. It's incredibly powerful. It's just a
matter of whether that will be forever tied to Windows and Azure, or be set
free.

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 7 Jan 2018

👍3 👎1

+1 to Scott

Sent via Morse code.

On Jan 7, 2018, at 5:13 PM, Scott Hurlbert notifications@github.com wrote:

Agreed - "WCF enables best-in-class SOA. It's incredibly powerful."

The purpose of this list was to gauge interest.

Other peopel's lack of interest or ability to "do it another way using none
.NET libraries" in any way addresses the question that was asked and the
reasons for our responses.

Also, the purpose of this was not to educate each other on SOA and all of
the thousands of ways it can be achieved. The question was put out "Should
WCF be added to .NET core."

If I'm trying to get a team to use WCF, the single biggest selling point I
have is that it's part of the .NET framework. Why? Because I'm an
experienced guy and most of the audience is managers, PMs, junior
developers, developers, or junior architects. There are maybe 2 or 3
people on any given team that understand anything about SO. The reason
they have guys "like us" on the team is to make quality recommendations and
using what's right in front of you that is industrial strength, proven, and
enterprise ready is a pretty good thing to suggest.

Can SO be done on .NET in other ways? No one here is asking that question
(or at least that's not the purpose of this thread).

On Sun, Jan 7, 2018 at 11:34 AM, ccicchitelli notifications@github.com
wrote:

"everything you can do in node without a third party lib is exactly the
same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party, I'm going to
pick the one with the larger and more active community, with the larger
corporate backing. Right now that's Node and JS, not .NET Core and C#.

WCF enables best-in-class SOA. It's incredibly powerful. It's just a
matter of whether that will be forever tied to Windows and Azure, or be set
free.

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

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

websitewill on 7 Jan 2018

The only reason I want WCF server side is to integrate with the large
number of existing SOAP/HTTP services out there. The rest of WCF? There are
numerous, and better, frameworks for that. But existing SOAP services, and
the requirement to integrate with them, is huge.

On Sun, Jan 7, 2018 at 4:46 PM websitewill notifications@github.com wrote:

+1 to Scott

Sent via Morse code.

On Jan 7, 2018, at 5:13 PM, Scott Hurlbert notifications@github.com
wrote:

Agreed - "WCF enables best-in-class SOA. It's incredibly powerful."

The purpose of this list was to gauge interest.

Other peopel's lack of interest or ability to "do it another way using
none
.NET libraries" in any way addresses the question that was asked and the
reasons for our responses.

Also, the purpose of this was not to educate each other on SOA and all of
the thousands of ways it can be achieved. The question was put out
"Should
WCF be added to .NET core."

If I'm trying to get a team to use WCF, the single biggest selling point
I
have is that it's part of the .NET framework. Why? Because I'm an
experienced guy and most of the audience is managers, PMs, junior
developers, developers, or junior architects. There are maybe 2 or 3
people on any given team that understand anything about SO. The reason
they have guys "like us" on the team is to make quality recommendations
and
using what's right in front of you that is industrial strength, proven,
and
enterprise ready is a pretty good thing to suggest.

Can SO be done on .NET in other ways? No one here is asking that question
(or at least that's not the purpose of this thread).

On Sun, Jan 7, 2018 at 11:34 AM, ccicchitelli notifications@github.com
wrote:

"everything you can do in node without a third party lib is exactly the
same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party, I'm going
to
pick the one with the larger and more active community, with the larger
corporate backing. Right now that's Node and JS, not .NET Core and C#.

WCF enables best-in-class SOA. It's incredibly powerful. It's just a
matter of whether that will be forever tied to Windows and Azure, or
be set
free.

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

.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

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

wasabii on 9 Jan 2018

As written above you don't need WCF for SOAP.

Am 09.01.2018 05:56 schrieb "Jerome Haltom" notifications@github.com:

The only reason I want WCF server side is to integrate with the large
number of existing SOAP/HTTP services out there. The rest of WCF? There are
numerous, and better, frameworks for that. But existing SOAP services, and
the requirement to integrate with them, is huge.

On Sun, Jan 7, 2018 at 4:46 PM websitewill notifications@github.com
wrote:

+1 to Scott

Sent via Morse code.

On Jan 7, 2018, at 5:13 PM, Scott Hurlbert notifications@github.com
wrote:

Agreed - "WCF enables best-in-class SOA. It's incredibly powerful."

The purpose of this list was to gauge interest.

Other peopel's lack of interest or ability to "do it another way using
none
.NET libraries" in any way addresses the question that was asked and
the
reasons for our responses.

Also, the purpose of this was not to educate each other on SOA and all
of
the thousands of ways it can be achieved. The question was put out
"Should
WCF be added to .NET core."

If I'm trying to get a team to use WCF, the single biggest selling
point
I
have is that it's part of the .NET framework. Why? Because I'm an
experienced guy and most of the audience is managers, PMs, junior
developers, developers, or junior architects. There are maybe 2 or 3
people on any given team that understand anything about SO. The reason
they have guys "like us" on the team is to make quality recommendations
and
using what's right in front of you that is industrial strength, proven,
and
enterprise ready is a pretty good thing to suggest.

Can SO be done on .NET in other ways? No one here is asking that
question
(or at least that's not the purpose of this thread).

On Sun, Jan 7, 2018 at 11:34 AM, ccicchitelli <
[email protected]>
wrote:

"everything you can do in node without a third party lib is exactly
the
same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party, I'm going
to
pick the one with the larger and more active community, with the
larger
corporate backing. Right now that's Node and JS, not .NET Core and
C#.

WCF enables best-in-class SOA. It's incredibly powerful. It's just a
matter of whether that will be forever tied to Windows and Azure, or
be set
free.

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

.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908> <(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

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

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

forki on 9 Jan 2018

Helps, when you have more advanced services. Reliable sessions,
transactions, etc. And MTOM.

On Jan 8, 2018 11:44 PM, "Steffen Forkmann" notifications@github.com
wrote:

As written above you don't need WCF for SOAP.

Am 09.01.2018 05:56 schrieb "Jerome Haltom" notifications@github.com:

The only reason I want WCF server side is to integrate with the large
number of existing SOAP/HTTP services out there. The rest of WCF? There
are
numerous, and better, frameworks for that. But existing SOAP services,
and
the requirement to integrate with them, is huge.

On Sun, Jan 7, 2018 at 4:46 PM websitewill notifications@github.com
wrote:

+1 to Scott

Sent via Morse code.

On Jan 7, 2018, at 5:13 PM, Scott Hurlbert <[email protected]

wrote:
>

Agreed - "WCF enables best-in-class SOA. It's incredibly powerful."

The purpose of this list was to gauge interest.

Other peopel's lack of interest or ability to "do it another way
using
none
.NET libraries" in any way addresses the question that was asked and
the
reasons for our responses.

Also, the purpose of this was not to educate each other on SOA and
all
of
the thousands of ways it can be achieved. The question was put out
"Should
WCF be added to .NET core."

If I'm trying to get a team to use WCF, the single biggest selling
point
I
have is that it's part of the .NET framework. Why? Because I'm an
experienced guy and most of the audience is managers, PMs, junior
developers, developers, or junior architects. There are maybe 2 or
3
people on any given team that understand anything about SO. The
reason
they have guys "like us" on the team is to make quality
recommendations
and
using what's right in front of you that is industrial strength,
proven,
and
enterprise ready is a pretty good thing to suggest.

Can SO be done on .NET in other ways? No one here is asking that
question
(or at least that's not the purpose of this thread).

On Sun, Jan 7, 2018 at 11:34 AM, ccicchitelli <
[email protected]>
wrote:

"everything you can do in node without a third party lib is exactly
the
same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party, I'm
going
to
pick the one with the larger and more active community, with the
larger
corporate backing. Right now that's Node and JS, not .NET Core and
C#.

WCF enables best-in-class SOA. It's incredibly powerful. It's just
a
matter of whether that will be forever tied to Windows and Azure,
or
be set
free.

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

.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908> <(415)%20378-9908>
<(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

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

—
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-356180160, or
mute
the thread
16mXuYAjtzSVCj2cA7HkJ0jks5tIvGTgaJpZM4Ikmmx>
.

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

wasabii on 9 Jan 2018

There are better ways to do those things now (though the first two I’d
argue are detrimental to a SOA)

On Tue, Jan 9, 2018 at 12:45 AM Jerome Haltom notifications@github.com
wrote:

Helps, when you have more advanced services. Reliable sessions,
transactions, etc. And MTOM.

On Jan 8, 2018 11:44 PM, "Steffen Forkmann" notifications@github.com
wrote:

As written above you don't need WCF for SOAP.

Am 09.01.2018 05:56 schrieb "Jerome Haltom" notifications@github.com:

The only reason I want WCF server side is to integrate with the large
number of existing SOAP/HTTP services out there. The rest of WCF? There
are
numerous, and better, frameworks for that. But existing SOAP services,
and
the requirement to integrate with them, is huge.

On Sun, Jan 7, 2018 at 4:46 PM websitewill notifications@github.com
wrote:

+1 to Scott

Sent via Morse code.

On Jan 7, 2018, at 5:13 PM, Scott Hurlbert <
[email protected]

wrote:
>

Agreed - "WCF enables best-in-class SOA. It's incredibly powerful."

The purpose of this list was to gauge interest.

Other peopel's lack of interest or ability to "do it another way
using
none
.NET libraries" in any way addresses the question that was asked
and
the
reasons for our responses.

Also, the purpose of this was not to educate each other on SOA and
all
of
the thousands of ways it can be achieved. The question was put out
"Should
WCF be added to .NET core."

If I'm trying to get a team to use WCF, the single biggest selling
point
I
have is that it's part of the .NET framework. Why? Because I'm an
experienced guy and most of the audience is managers, PMs, junior
developers, developers, or junior architects. There are maybe 2
or
3
people on any given team that understand anything about SO. The
reason
they have guys "like us" on the team is to make quality
recommendations
and
using what's right in front of you that is industrial strength,
proven,
and
enterprise ready is a pretty good thing to suggest.

Can SO be done on .NET in other ways? No one here is asking that
question
(or at least that's not the purpose of this thread).

On Sun, Jan 7, 2018 at 11:34 AM, ccicchitelli <
[email protected]>
wrote:

"everything you can do in node without a third party lib is
exactly
the
same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party, I'm
going
to
pick the one with the larger and more active community, with the
larger
corporate backing. Right now that's Node and JS, not .NET Core
and
C#.

WCF enables best-in-class SOA. It's incredibly powerful. It's
just
a
matter of whether that will be forever tied to Windows and Azure,
or
be set
free.

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

.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908> <(415)%20378-9908>
<(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the
thread.

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

—
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-356180160, or
mute
the thread
16mXuYAjtzSVCj2cA7HkJ0jks5tIvGTgaJpZM4Ikmmx>
.

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

.

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

jbogard on 9 Jan 2018

In regards to all the alternatives and possibilities discussed here, I just want to say:

There is nothing even comparable with Full framework WCF in terms of flexibility and interoperability

Now, are there better choices for SOA architectures? Yes ... and No. It all depends on how green is your field and what are you trying to build. Is REST better choice for an SOA architecture? No ... and Yes, but depends on what you are trying to build. Is an AMQP library the best choice? ... Ok, you're catching my drift ...

I don't think this discussion should be about what's best for an SOA architecture (which lacks requirements or description, by the way, and everyone imagines something different) ...but about the fact that .Net Core lacks a flexible and interoperable communication framework that would allow it to be used in "not so green fields" or "gradual migrations" completely locking a set of potential projects out (Especially large enterprise migration projects suffer here).

Some final thoughts:
- SOAP is a thing of the past, no question about it.
- WS-* is overly complex
- There are better, faster, more modern communication solutions

But all of the above don't mean WCF should be discarded, quite the contrary, WCF is needed to solve the above issues for it's users.

popcatalin81 on 9 Jan 2018

👍2

I keep saying this on this list, just because you don't want to use WCF is
not the same as our team not needing it.

@bogard's comment that there are ways without mentioning what they are is
like that joke in the movie King Pin. In the movie they keep saying, "Well
you know what the Bible says about that?" After a pause they say, "It's
against it," or "It's for it." They don't cite a passage, just the belief
in their opinion.

I don't think this list in the right place to have a SOA discussion, but to
say there are "better ways" and then mention nothing is bit disingenuous.
And, I've been consistent in pointing out that, just because you don't need
WCF or think solution Xyz is "better" doesn't mean that it would fit my
specifications. That goes double for things un-cited.

You know what the Bible says about mentioning how awesome something is
without saying what is is, don't you? It's against it.

On Tue, Jan 9, 2018 at 6:00 AM, Jimmy Bogard notifications@github.com
wrote:

There are better ways to do those things now (though the first two I’d
argue are detrimental to a SOA)

On Tue, Jan 9, 2018 at 12:45 AM Jerome Haltom notifications@github.com
wrote:

Helps, when you have more advanced services. Reliable sessions,
transactions, etc. And MTOM.

On Jan 8, 2018 11:44 PM, "Steffen Forkmann" notifications@github.com
wrote:

As written above you don't need WCF for SOAP.

Am 09.01.2018 05:56 schrieb "Jerome Haltom" <[email protected]
:

The only reason I want WCF server side is to integrate with the large
number of existing SOAP/HTTP services out there. The rest of WCF?
There
are
numerous, and better, frameworks for that. But existing SOAP
services,
and
the requirement to integrate with them, is huge.

On Sun, Jan 7, 2018 at 4:46 PM websitewill <[email protected]

wrote:

+1 to Scott

Sent via Morse code.

On Jan 7, 2018, at 5:13 PM, Scott Hurlbert <
[email protected]

wrote:
>

Agreed - "WCF enables best-in-class SOA. It's incredibly
powerful."

The purpose of this list was to gauge interest.

Other peopel's lack of interest or ability to "do it another way
using
none
.NET libraries" in any way addresses the question that was asked
and
the
reasons for our responses.

Also, the purpose of this was not to educate each other on SOA
and
all
of
the thousands of ways it can be achieved. The question was put
out
"Should
WCF be added to .NET core."

If I'm trying to get a team to use WCF, the single biggest
selling
point
I
have is that it's part of the .NET framework. Why? Because I'm an
experienced guy and most of the audience is managers, PMs, junior
developers, developers, or junior architects. There are maybe 2
or
3
people on any given team that understand anything about SO. The
reason
they have guys "like us" on the team is to make quality
recommendations
and
using what's right in front of you that is industrial strength,
proven,
and
enterprise ready is a pretty good thing to suggest.

Can SO be done on .NET in other ways? No one here is asking that
question
(or at least that's not the purpose of this thread).

On Sun, Jan 7, 2018 at 11:34 AM, ccicchitelli <
[email protected]>
wrote:

"everything you can do in node without a third party lib is
exactly
the
same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party, I'm
going
to
pick the one with the larger and more active community, with
the
larger
corporate backing. Right now that's Node and JS, not .NET Core
and
C#.

WCF enables best-in-class SOA. It's incredibly powerful. It's
just
a
matter of whether that will be forever tied to Windows and
Azure,
or
be set
free.

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

.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908> <(415)%20378-9908>
<(415)%20378-9908>
<(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the
thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/dotnet/wcf/issues/1200#issuecomment-355859316
,
or
mute
the thread
AAhjSomkpRNu8TdYb3nIrq3nRj1O3FkTks5tIUk5gaJpZM4Ikmmx>
.

—
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-356180160,
or
mute
the thread
16mXuYAjtzSVCj2cA7HkJ0jks5tIvGTgaJpZM4Ikmmx>
.

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

.

—
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-356194891, or
mute
the thread
wu7sRd4wGwY4EiqMxKuGUtFks5tIwr1gaJpZM4Ikmmx>

.

—
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-356291599, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABo_ErRkJ8-RGkcDRZAo1f9RFz-Cfvddks5tI3EOgaJpZM4Ikmmx
.

--
Scott Hurlbert
Technical Architect
415-378-9908
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

scotthurlbert on 9 Jan 2018

Honestly before this thread I thought folks had generally moved on. In
terms of better replacements, what parts of WCF?

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)

I do have banking clients that still use expensive ESBs they purchased with
a golf course handshake back in 2004, so I can empathize with the legacy
interop story. I've just attacked this by creating a shim between their
stuff and mine.

On Tue, Jan 9, 2018 at 9:26 AM, Scott Hurlbert notifications@github.com
wrote:

I keep saying this on this list, just because you don't want to use WCF is
not the same as our team not needing it.

@bogard's comment that there are ways without mentioning what they are is
like that joke in the movie King Pin. In the movie they keep saying, "Well
you know what the Bible says about that?" After a pause they say, "It's
against it," or "It's for it." They don't cite a passage, just the belief
in their opinion.

I don't think this list in the right place to have a SOA discussion, but to
say there are "better ways" and then mention nothing is bit disingenuous.
And, I've been consistent in pointing out that, just because you don't need
WCF or think solution Xyz is "better" doesn't mean that it would fit my
specifications. That goes double for things un-cited.

You know what the Bible says about mentioning how awesome something is
without saying what is is, don't you? It's against it.

On Tue, Jan 9, 2018 at 6:00 AM, Jimmy Bogard notifications@github.com
wrote:

There are better ways to do those things now (though the first two I’d
argue are detrimental to a SOA)

On Tue, Jan 9, 2018 at 12:45 AM Jerome Haltom notifications@github.com
wrote:

Helps, when you have more advanced services. Reliable sessions,
transactions, etc. And MTOM.

On Jan 8, 2018 11:44 PM, "Steffen Forkmann" notifications@github.com
wrote:

As written above you don't need WCF for SOAP.

Am 09.01.2018 05:56 schrieb "Jerome Haltom" <
[email protected]
:

The only reason I want WCF server side is to integrate with the
large
number of existing SOAP/HTTP services out there. The rest of WCF?
There
are
numerous, and better, frameworks for that. But existing SOAP
services,
and
the requirement to integrate with them, is huge.

On Sun, Jan 7, 2018 at 4:46 PM websitewill <
[email protected]

wrote:

+1 to Scott

Sent via Morse code.

On Jan 7, 2018, at 5:13 PM, Scott Hurlbert <
[email protected]

wrote:
>

Agreed - "WCF enables best-in-class SOA. It's incredibly
powerful."

The purpose of this list was to gauge interest.

Other peopel's lack of interest or ability to "do it another
way
using
none
.NET libraries" in any way addresses the question that was
asked
and
the
reasons for our responses.

Also, the purpose of this was not to educate each other on SOA
and
all
of
the thousands of ways it can be achieved. The question was put
out
"Should
WCF be added to .NET core."

If I'm trying to get a team to use WCF, the single biggest
selling
point
I
have is that it's part of the .NET framework. Why? Because I'm
an
experienced guy and most of the audience is managers, PMs,
junior
developers, developers, or junior architects. There are
maybe 2
or
3
people on any given team that understand anything about SO. The
reason
they have guys "like us" on the team is to make quality
recommendations
and
using what's right in front of you that is industrial strength,
proven,
and
enterprise ready is a pretty good thing to suggest.

Can SO be done on .NET in other ways? No one here is asking
that
question
(or at least that's not the purpose of this thread).

On Sun, Jan 7, 2018 at 11:34 AM, ccicchitelli <
[email protected]>
wrote:

"everything you can do in node without a third party lib is
exactly
the
same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party,
I'm
going
to
pick the one with the larger and more active community, with
the
larger
corporate backing. Right now that's Node and JS, not .NET
Core
and
C#.

WCF enables best-in-class SOA. It's incredibly powerful. It's
just
a
matter of whether that will be forever tied to Windows and
Azure,
or
be set
free.

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

.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908> <(415)%20378-9908>
<(415)%20378-9908>
<(415)%20378-9908>
<(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the
thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/dotnet/wcf/issues/1200#issuecomment-
355859316
,
or
mute
the thread
AAhjSomkpRNu8TdYb3nIrq3nRj1O3FkTks5tIUk5gaJpZM4Ikmmx>
.

—
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-356180160
,
or
mute
the thread
16mXuYAjtzSVCj2cA7HkJ0jks5tIvGTgaJpZM4Ikmmx>
.

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

.

—
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-356194891, or
mute
the thread
wu7sRd4wGwY4EiqMxKuGUtFks5tIwr1gaJpZM4Ikmmx>

.

—
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-356291599, or
mute
the thread
RGkcDRZAo1f9RFz-Cfvddks5tI3EOgaJpZM4Ikmmx>
.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/

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

jbogard on 9 Jan 2018

👍1

Jimmy: "Honestly before this thread I thought folks had generally moved on"
Not at all - not even a remote possibility in the near (5-10 year) future
for many enterprises.
In fact, from what I see, adoption of WCF has increased - just not using it
for web services - so it's not as in-your-face.

Many enterprise-scale apps use WCF behind the scenes and would benefit from
hosting on cheaper metal - but they can't.
The cost to rewrite those apps (systems) would be huge - not only in
actual manpower lost, but in opportunity loss while doing an entire rewrite.
Also:
Security costs - we know how to secure WCF, and using WCF for all
services/layers provides the same security story throughout. Switching to a
more hybrid approach would mean figuring out how to secure, tune, manage,
etc a BUNCH of different tools - when one tool does all we need, and does
it very well.

The problem is that almost everyone fixates on using WCF for web services
which is, in reality, is only a very small percentage of how it is actually
used. This is because, if you Google for WCF, that's pretty much all you
find in the "how to" sections. WCF is a communication FRAMEWORK (useful
across the entire applications stack from client, business, resource
access, etc). It's NOT just about exposing web services to clients - which
is what most people who don't use it (and therefore have ZERO actual skin
in the game) are aware of. If that's all it was, it would be called
something like MSWSF (Microsoft Web Services Framework). The "Communication
Framework" was intentional.

Will

On Tue, Jan 9, 2018 at 10:50 AM, Jimmy Bogard notifications@github.com
wrote:

Honestly before this thread I thought folks had generally moved on. In
terms of better replacements, what parts of WCF?

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)

I do have banking clients that still use expensive ESBs they purchased with
a golf course handshake back in 2004, so I can empathize with the legacy
interop story. I've just attacked this by creating a shim between their
stuff and mine.

On Tue, Jan 9, 2018 at 9:26 AM, Scott Hurlbert notifications@github.com
wrote:

I keep saying this on this list, just because you don't want to use WCF
is
not the same as our team not needing it.

@bogard's comment that there are ways without mentioning what they are is
like that joke in the movie King Pin. In the movie they keep saying,
"Well
you know what the Bible says about that?" After a pause they say, "It's
against it," or "It's for it." They don't cite a passage, just the belief
in their opinion.

I don't think this list in the right place to have a SOA discussion, but
to
say there are "better ways" and then mention nothing is bit disingenuous.
And, I've been consistent in pointing out that, just because you don't
need
WCF or think solution Xyz is "better" doesn't mean that it would fit my
specifications. That goes double for things un-cited.

You know what the Bible says about mentioning how awesome something is
without saying what is is, don't you? It's against it.

On Tue, Jan 9, 2018 at 6:00 AM, Jimmy Bogard notifications@github.com
wrote:

There are better ways to do those things now (though the first two I’d
argue are detrimental to a SOA)

On Tue, Jan 9, 2018 at 12:45 AM Jerome Haltom <
[email protected]>
wrote:

Helps, when you have more advanced services. Reliable sessions,
transactions, etc. And MTOM.

On Jan 8, 2018 11:44 PM, "Steffen Forkmann" <
[email protected]>
wrote:

As written above you don't need WCF for SOAP.

Am 09.01.2018 05:56 schrieb "Jerome Haltom" <
[email protected]
:

The only reason I want WCF server side is to integrate with the
large
number of existing SOAP/HTTP services out there. The rest of WCF?
There
are
numerous, and better, frameworks for that. But existing SOAP
services,
and
the requirement to integrate with them, is huge.

On Sun, Jan 7, 2018 at 4:46 PM websitewill <
[email protected]

wrote:

+1 to Scott

Sent via Morse code.

On Jan 7, 2018, at 5:13 PM, Scott Hurlbert <
[email protected]

wrote:
>

Agreed - "WCF enables best-in-class SOA. It's incredibly
powerful."

The purpose of this list was to gauge interest.

Other peopel's lack of interest or ability to "do it another
way
using
none
.NET libraries" in any way addresses the question that was
asked
and
the
reasons for our responses.

Also, the purpose of this was not to educate each other on
SOA
and
all
of
the thousands of ways it can be achieved. The question was
put
out
"Should
WCF be added to .NET core."

If I'm trying to get a team to use WCF, the single biggest
selling
point
I
have is that it's part of the .NET framework. Why? Because
I'm
an
experienced guy and most of the audience is managers, PMs,
junior
developers, developers, or junior architects. There are
maybe 2
or
3
people on any given team that understand anything about SO.
The
reason
they have guys "like us" on the team is to make quality
recommendations
and
using what's right in front of you that is industrial
strength,
proven,
and
enterprise ready is a pretty good thing to suggest.

Can SO be done on .NET in other ways? No one here is asking
that
question
(or at least that's not the purpose of this thread).

On Sun, Jan 7, 2018 at 11:34 AM, ccicchitelli <
[email protected]>
wrote:

"everything you can do in node without a third party lib is
exactly
the
same as what you can do in asp.net core without a lib."

That's exactly what I said. And since it's all third-party,
I'm
going
to
pick the one with the larger and more active community,
with
the
larger
corporate backing. Right now that's Node and JS, not .NET
Core
and
C#.

WCF enables best-in-class SOA. It's incredibly powerful.
It's
just
a
matter of whether that will be forever tied to Windows and
Azure,
or
be set
free.

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

.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908> <(415)%20378-9908>
<(415)%20378-9908>
<(415)%20378-9908>
<(415)%20378-9908>
<(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the
thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/dotnet/wcf/issues/1200#issuecomment-
355859316
,
or
mute
the thread
AAhjSomkpRNu8TdYb3nIrq3nRj1O3FkTks5tIUk5gaJpZM4Ikmmx>
.

—
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-
356180160
,
or
mute
the thread
16mXuYAjtzSVCj2cA7HkJ0jks5tIvGTgaJpZM4Ikmmx>
.

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

.

—
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-356194891,
or
mute
the thread
wu7sRd4wGwY4EiqMxKuGUtFks5tIwr1gaJpZM4Ikmmx>

.

—
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-356291599, or
mute
the thread
RGkcDRZAo1f9RFz-Cfvddks5tI3EOgaJpZM4Ikmmx>
.

--
Scott Hurlbert
Technical Architect
415-378-9908 <(415)%20378-9908> <(415)%20378-9908>
[email protected]
AIM: scottahurlbert
Skype: hurlbert
GTalk: [email protected]
Blogs:

https://medium.com/@hurlbert

http://oknowwhatfolks.blogspot.com/

http://agilecliches.blogspot.com/

—
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-356316411, or
mute
the thread
AAGYMlOEarlLSbG3Ivxj6oam53cjxayIks5tI4U0gaJpZM4Ikmmx>
.

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

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

websitewill on 9 Jan 2018

Yes, because WCF is and has always been all about web services!

RPC?! There's no RPC in WCF. It is stackless, which is a key aspect that makes it superior in every respect to anything else available that you know about.

TCP?! Um, so, it seems you do not understand that WCF features location transparency. I do not have to write pipe code, or tcp code, or msmq code, or amqp code, or service bus code. I write my code. 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.

Of the legitimate needs listed here, reliability, transactions, throttling, bindings, etc, etc, etc you will not find any comparable replacement, none, because it does not exist. So, for those of us that actually need those features we have not moved on. Some of us are able to move on to a true service oriented platform (Service Fabric) but for infrastructure, we still very much need WCF.

It is clear that many that have commented here have absolutely no idea what WCF is or what it is for or how many of us use it. I'm not sure it's fair for those voices to remain in the conversation. If you think that WCF is all about web services and there's better stuff out there then you really do not have any idea what some of us are talking about and your time might be better spent in another conversation. I know my time here would be better spent having an actual conversation about the subject with actual practitioners who actually have experience with these systems.

shamusfuller on 9 Jan 2018

👍1

The last two comments here hit the nail on the head and I couldn't agree more. It is called "Communication Foundation" for a reason. "Moved on"? Putting that out there is essentially telling every customer currently using WCF (in whatever capacity) that they have always been doing it wrong and they should get with the program - very unfair thing to say. It seems to me that a common pattern in the certain parts of the Microsoft community is that the minute there is another way of doing something, the previous way is now labeled wrong or idiotic and therefore dead. if it ain't what the cool kids are using then you must be a moron. Call me old-school, but for my customers it's about solving a problem and providing value. WCF did and does that very well. I agree with Will. It's way more than doing web services. But the fact that it can do them too is still great. Why go through a list of ten products that can each offer an alternative to a single feature of WCF when I know I can do it using WCF? I use WCF in so many other capacities and in conjunction with Web API and ASP Core. I've set up solutions using WCF's discovery and content-based routing, and that shit rocks. There isn't anything else out there that can do it as well or as easily.

miguelcastro67 on 9 Jan 2018

Tbf it's not the .NET Community that moved on. It's the rest of the industry. And it's hard to justify SOA things if that means .NET to .NET communication only. But of course you want to maintain legacy stuff - and you can. Full framework won't go away. We just got a new version.

forki on 9 Jan 2018

The cost to rewrite those apps (systems) would be huge - not only in actual manpower lost, but in opportunity loss while doing an entire rewrite.

Hate to be that guy, but how exactly is your business supposed to respond to evolving market conditions if this is the case? Is your database access code coupled to WCF in some way?

thefringeninja on 9 Jan 2018

Steffen: Tbf, where is your data to back that claim up?

On Tue, Jan 9, 2018 at 11:43 AM, Steffen Forkmann notifications@github.com
wrote:

Tbf it's not the .NET Community that moved on. It's the rest of the
industry. And it's hard to justify SOA things if that means .NET to .NET
communication only. But of course you want to maintain legacy stuff - and
you can. Full framework won't go away. We just got a new version.

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

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

websitewill on 9 Jan 2018

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

forki on 9 Jan 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 on 9 Jan 2018

SOAP is Not Dead – It’s Undead, a Zombie in the Enterprise

mtiymzi2njy0mdk2mtu0mje0

damianh on 9 Jan 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 on 9 Jan 2018

Nope, my data access code is 100% data access.
I don't have to write ANYTHING related to queuing, transactions (across the
entire stack across processes and threads), security, concurrency,
reliability, *ability, etc.
Does your resource access have any of those smells?
My data access is exposed as a SERVICE - not a web service, but a service,
with all the benefits thereof. Coupling is ALL contracts, all the time -
nothing else. It's what a SOA does, and you need good plumbing behind a
SOA, otherwise, your dev teams have to be kung-fu masters in a bunch of
arbitrary (and constantly changing) environments.

By the way, "latest and greatest" aren't what enterprises are interested
in. Getting stuff done and producing features/products is.

It is precisely my use of WCF that allows my ecosystems to thrive and
iterate. Basically look at WCF as .NET on steroids, NOT just web services.

And again, IF you aren't using WCF, then why are you here?
This thread is about people who want to get a solid, streamlined,
full-featured, singular communication stack into .NET Core so we can host
on cheaper metal and smaller devices, NOT about whatever kung-fu you
require your teams to perform.

On Tue, Jan 9, 2018 at 11:44 AM, João Bragança notifications@github.com
wrote:

The cost to rewrite those apps (systems) would be huge - not only in
actual manpower lost, but in opportunity loss while doing an entire rewrite.

Hate to be that guy, but how exactly is your business supposed to respond
to evolving market conditions if this is the case? Is your database access
code coupled to WCF in some 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-356341779, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ASs0gXXZoPmFKKS8U9PC0GTHvqsaTeiGks5tI5d0gaJpZM4Ikmmx
.

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

websitewill on 9 Jan 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 on 9 Jan 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 on 9 Jan 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 on 9 Jan 2018

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

Sent from my iPhone

On 10 Jan 2018, at 12:54 AM, Suriman notifications@github.com wrote:

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.

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

phillip-haydon on 9 Jan 2018

❤2

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

This point seems lost on many.

ccicchitelli on 9 Jan 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 on 9 Jan 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 on 9 Jan 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 on 9 Jan 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 on 9 Jan 2018

This says much more about you than it does anything about any technology.

We are not here to educate those who insist upon remaining ignorant of good
tools. You can continue to drive screws with your hammer if you choose.
Move along.

On Tue, Jan 9, 2018 at 11:59 AM, Damian Hickey notifications@github.com
wrote:

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 :)

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

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

websitewill on 9 Jan 2018

Anyone who thinks Microsoft has "moved on" obviously hasn't talked with any
of the teams building Azure - leveraging LOTS of WCF behind it.
Hrmmmm.

On Tue, Jan 9, 2018 at 12:02 PM, Damian Hickey notifications@github.com
wrote:

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 :)

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

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

websitewill on 9 Jan 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 on 9 Jan 2018

Damianh ad hominem attacks aren't appreciated.

ccicchitelli on 9 Jan 2018

And my lack of any public repositories means, what, exactly?
That I work for people who choose to not give away their code?
That I don't work on many open-source projects?

Kudos on your evidence of... What, exactly? :)

On Tue, Jan 9, 2018 at 12:06 PM, Damian Hickey notifications@github.com
wrote:

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

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

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

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

websitewill on 9 Jan 2018

👍1

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.

blowdart on 9 Jan 2018

👍4 ❤1 🎉1

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 on 9 Jan 2018

👍1

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

ccicchitelli on 9 Jan 2018

For exposing service outside the fire, yes, of course. But gain, that's a
very small part of the concern WCF is used for.
IMO, I don't even use WCF for that part because yes, Web API (or now just
MVC).

That's focusing on only one tiny thing, which is the problem with this
thread as that's pretty much what most of the population knows about WCF,
which is a shame.

That's like saying .NET is only about int and string.

On Tue, Jan 9, 2018 at 12:14 PM, Mike Mogosanu notifications@github.com
wrote:

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.

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

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

websitewill on 9 Jan 2018

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

damianh on 9 Jan 2018

👎2

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 on 9 Jan 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 on 9 Jan 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 on 9 Jan 2018

👍1

@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 on 9 Jan 2018

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

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

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

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

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

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

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

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

websitewill on 9 Jan 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 on 9 Jan 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 on 9 Jan 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 on 9 Jan 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 on 9 Jan 2018

👍1

"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 on 9 Jan 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 on 9 Jan 2018

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

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

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

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

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

scotthurlbert on 9 Jan 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 on 9 Jan 2018

Wcf: Server side WCF

Most helpful comment

All 264 comments

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

.NET Core - WCF Support Survey

Related issues