
WCF is Open Source - Vitallium
http://www.dotnetfoundation.org/blog/wcf-is-open-source
======
skrebbel
I love C# and .NET, but WCF is a true source of frustration. It isn't horribly
bad, but there is _nothing_ good about it either. It's too complex, too messy,
and too "Microsofty" for lack of a better word. Many layers of abstraction,
hidden magic in XML files (which you can of course turn off, but then you need
to know how to), and so on. Nevertheless, shares of coders blindly use WCF,
"because Microsoft tells us to". Bullshit, and what a waste.

There are very few modern use cases where WCF is the best option out there. If
you want to make a RESTful API with .NET, please consider:

    
    
         * ASP.NET MVC Web API
         * ServiceStack
         * Nancy
    

Nancy is basically Ruby's Sinatra but then on .NET.

ServiceStack recently became commercial, but it still is the best designed API
library I've ever seen, _in any language_. It makes you focus more on the
_actual data_ inside each request and response, and less on the form of that
data (is it a query parameter, JSON POST field, or part of a fancy URL? who
cares, design your messages first and then figure out what the URLs should
look like). The result of this is that somehow you tend to automatically
design forward-compatible, extensible API endpoints. I guess you really have
to feel it to believe it, but I kid you not, with ServiceStack, it feels like
your API designs itself in front of your eyes.

If anyone knows anything like ServiceStack on any other language, please tell
me and I'm going to give you hugs.

Finally, MVC Web API is basically Rails's API controllers ported to C#. It has
a tad too much magic for my taste, but it's a familiar and decent pattern that
just works.

Please, please, let's just bury WCF and embrace the true goodies in the .NET
open source ecosystem. It's nice that WCF got open sourced, but it's still a
mess. If you really must go the "because Microsoft!" route, please just use
ASP.NET MVC (also open source, and in active development).

~~~
ilitirit
It's worth remembering that the technologies you mentioned weren't around when
WCF was created.

As far as I can tell, Microsoft doesn't really push WCF any more simply
because the use-cases are fewer and/or irrelevant in the current Web Service
landscape.

I also get the feeling that many people commenting here didn't need to work
with WS-* and associated technologies at the time WCF didn't exist. After its
release it really was a choice between the lesser of two evils. But at the
time, WCF was the mischievous kid who didn't do his homework, and everything
else was the direct spawn of Satan.

A reminder of what WCF is (Wikipedia):

> a runtime and a set of APIs in the .NET Framework for building connected,
> _service-oriented applications_

> WCF is a tool often used to implement and deploy a _service-oriented
> architecture (SOA)_

For people who were around during the SOA dark ages, I won't be surprised if
reading that sent shivers down your spine. Thankfully SOA, as it was
evangelized, is pretty much dead. For everything else, these days better data-
interchange technologies exist.

~~~
mattmanser
Wasn't there web services before WCF to deal with SOAP? And I seem to remember
they were easier to use than WCF. I also go the feeling that when WCF was
released it killed off quite a bit of the evolving open source stuff.

Could be wrong, but you seem to be downplaying how much of a development drag
WCF ended up being on .Net and how poorly it is designed.

I was around that time too, and for me WCF was like a blast from the past even
back then. It was like a bad .Net 1.0 library when it was brought out. Almost
everything they could design badly and enterprisey, they managed to design
badly and enterprisey. It reminded me of that terrible enterprise library they
had.

Still pretty useful in consuming Salesforce's terrible api though.

~~~
ilitirit
> Wasn't there web services before WCF to deal with SOAP?

Yes, you used Web Services to deal with SOAP messages. But SOAP was never the
problem. WS-* was.

> These variety of specifications are the basic web services framework
> established by first-generation standards represented by WSDL, SOAP, and
> UDDI.[1] Specifications may complement, overlap, and compete with each
> other. Web service specifications are occasionally referred to collectively
> as "WS- __" , though there is not a single managed set of specifications
> that this consistently refers to, nor a recognized owning body across them
> all.

[http://en.wikipedia.org/wiki/List_of_web_service_specificati...](http://en.wikipedia.org/wiki/List_of_web_service_specifications)

I also don't understand why people think that "enterprisey" is inherently a
bad thing? _It was designed to be used in the enterprise._ This is evident in
it's relationship to SOA, which is basically its raison d'etre. When you build
apps in enterprise environments you have to put with all kinds of crap to
appease auditors and to adhere to various acts and governance frameworks and
protocols so that you can maintain your position on whatever Stock Exchange
etc. That's just the nature of the beast.

~~~
mattmanser
Enterprisey doesn't mean designed to work in an enterprise. It never has.

It's a pejorative term, not a descriptive one.

It means an over engineered solution to a simple problem that suffers heavily
from YAGNI. It means catering to the 0.1% scenarios over the 99.9% scenarios.
It means a complex generic solution where a simple one would have been better
with custom code being used to handle the occasional complex scenario.

~~~
ilitirit
> It means an over engineered solution to a simple problem

This is exactly my point. SOA in practice is _not_ a simple problem, and it's
the reason WCF exists so of course it's going to be complex. The whole idea of
SOA means that you're inherently stuck with the problem of communicating with
different different systems that talk different languages, by trying to coerce
them into communicating via a standard format, which for all intents and
purposes was rarely "standard". And of course these things have to be done in
a secure fashion, with logging and auditing every step of the way, and with
the ability to change configuration properties by editing a text file instead
of having to via a Change Control Board and the entire QA process.

My feeling is that people who were using WCF for "simple" problems were
probably using the wrong tool, even though in most cases it would have
probably worked fine.

~~~
mattmanser
No, the reason WCF exists is to share data between programs. It wasn't just
for SOA it was for everything.

Your over enthusiasm for WCF seems to stem from your own lack of understanding
of the major uses of WCF, you're citing a minor use case of WCF as if it were
the primary one.

Also the hints you're dropping of your work programming environment sounds
like a beauracratic nightmare.

~~~
ilitirit
Read the first sentence:

[https://msdn.microsoft.com/en-
us/library/ms731082%28v=vs.110...](https://msdn.microsoft.com/en-
us/library/ms731082%28v=vs.110%29.aspx)

------
tacos
Microsoft fanboy here. But... this product is total shit. Even if you're
tasked with some horror like talking to an overdesigned XML backend written in
Java nine years ago that uses an alternate canonicalization for digitally-
signed XML and requires a slightly-deviant form of SOAP authentication...
well, it'll eventually work.

The source won't help you. It's the least of your concerns.

This is exactly the type of overdesigned schlock that Microsoft occasionally
emits then gets stuck supporting because two big corporate clients signed on
after two junior devs watched an MSDN talk with the nutjob who architected it.
Avoid it.

~~~
jsingleton
I've been there and this tool is invaluable:
[http://www.soapui.org/](http://www.soapui.org/)

That and wireshark, and netmon. OK, I need to stop now or the repressed
memories will come back. :)

~~~
ilitirit
Sadly, even SOAP UI can't solve all your problems. WS-* is just so complex
that it's rare to find two sufficiently compatible implementations.

For example, on one WCF service I capture the message as it arrives and then
write to disk. If I replay this message through SOAP UI, it fails unless I
modify some of the headers.

WS-* just sucks in general.

~~~
jsingleton
Oh it doesn't make it easy! It just gives you a chance.

------
strommen
WCF is great if you want to make a single data service available as JSON via
REST, XML via SOAP, a custom binary protocol via raw TCP, and who-knows-what
else.

In practice you're almost always better off just picking a single format for
your endpoint, in which case there's no reason to use WCF.

~~~
scuba7183
What are some other libraries and frameworks that should be used? (For C# web
services)

~~~
arethuza
ASP.NET Web API

[http://www.asp.net/web-api](http://www.asp.net/web-api)

~~~
partisan
There is also a proxy generator for Web API so you still keep some of the
benefits of WCF.

[https://github.com/faniereynders/WebApiProxy/wiki/WebApi-C%2...](https://github.com/faniereynders/WebApiProxy/wiki/WebApi-C%23-Proxy-
Generator)

------
sudioStudio64
I've always been interested in WCF. This a good thing for those companies that
have lots of WCF services.

That being said...Scott Hanselman calls it WS-Death Star for a reason. (WS-*,
heh. Nerd Jokes. Check.) Hopefully this kick starts the same kind of rapid
evolution that Asp.net MVC had after it was open sourced.

~~~
anton_gogolev
> This a good thing for those companies that have lots of WCF services.

I very much doubt that. WCF is one of the most over-engineered frameworks I've
encountered so far, and I've seen many. It's an epitome of enterprisiness,
with every miniscule detail configurable via XML, with countless layers of
abstractions, factories and providers, with very specific modalities, with all
kinds of pluggable serializers, with metric ton of other crap. Because WS-*.

So it's very unlikely that some average developer will go spelunking through
the codebase to fix some obscure bug that occurs when interoperating with an
Apache Axis-based Java web service that is using WS-ReliableMessaging with WS-
Addressing over carrier pidgeons. Not gonna happen.

~~~
sudioStudio64
Couldn't they move to a more code and convention driven config system?

I know what you mean, though. I have this one web service that's the bane of
my existence. No WSDL, it's WS-Transfer and MEX and WS-Sec with it's own
STS...makes me weep thinking about it.

~~~
useerup
WCF does allow for code based configuration. There are actually 3 way to
configure everything in WCF: Imperative code, Declarative attributes and (xml-
based) config files.

Conventions are supported as well, but is woefully underused.

That said, WCF is a beast. If you need SOAP with federated security and bells
and whistles, it is a very solid choice.

If you can make it through with REST you should avoid WCF. It is a time sink.

------
daigoba66
A lot of people seem to focus on WCF has an over-engineered SOAP framework.
While that's very true, it is also the powerful successor to .NET original
remoting framework. So WCF represents the unification of several different
libraries and frameworks into one, for better or worse.

It would not surprise me to find enterprises still using WCF for interprocess
communication and/or remote method invocation. When both client and server are
.NET programs, most of the time it just works in my experience.

------
Roonerelli
WCF made the mistake of trying to be all the things to all the people

The abstraction is simply broken

It tried to be a common abstraction over http, tcp, message queue etc. Which
is just not possible

There's too many specifics in each of them to have any sort of common
interface (in all but the most simple examples)

~~~
Yuioup
Maybe now is the chance to fix it?

~~~
plorkyeran
You can't meaningfully fix something when the problem is that the core concept
is flawed.

------
WDCDev
WCF was built for the WS-* world, and as such is over-loaded with complexity
that is covered up by way way too much abstraction.

If you don't need WS-*, use Web API services self hosted with Katana if you
need to exchange data between applications/processes instead.

~~~
anton_gogolev
Oh, don't get me started on this whole Katana/OWIN disaster. Just look at all
these dependencies that are required to self-host ASP.NET application. How
they managed to complicate things so much -- I don't know.

NancyFX all the way.

~~~
jammycakes
One point to note here: OWIN and Katana are two separate components. OWIN is
the community-driven underlying abstraction layer which doesn't specify any
dependencies; Katana is a Microsoft-driven library of statically typed
wrappers around it that completely abstracts it out altogether and leaves you
with a bunch of tutorials and blog posts that don't look anything even
remotely like the OWIN spec. It's all very confusing.

I wrote a blog post about it a while ago trying to untangle the difference
between the two in some detail: [http://jamesmckay.net/2014/08/sorting-out-
the-confusion-that...](http://jamesmckay.net/2014/08/sorting-out-the-
confusion-that-is-owin-katana-and-iappbuilder/)

------
insulanian
"Windows Complication Foundation" is how we called it in my team :)

------
Glide
WCF is very powerful and a piece of frustration. What's interesting is that
most people have shared the common use of WCF which is interacting with Web
Services and being JSON endpoints. There are better alternatives to make JSON
endpoints in .NET. If you're using Web Services you're kind of stuck. So for a
lot of people this is going to be useful.

WCF is broad. Mind-bogglingly broad. I was in a project on we were
implementing a P2P system on top of WCF and WCF has some mesh capability built
in. Being able to use the same API for HTTP requests feels odd. Once I
understood the breadth of what it can do it really lives up to its name.
Unfortunately, it wasn't a focused API for most of what people needed it for.

------
iamthepieman
The first time I had to consume WS- services in .NET, with deeply nested data
types I spent a week trying to figure out WCF and the WS endpoint (which was
written in Java) and gave up.

I wrote a DSL to parse the messages and just stripped the message off the
network stack before it even hit the application level where WCF would handle
it. It gives me shivers just thinking about it.

~~~
ilitirit
Why did you go all the way down to that level? If you could not generate the
.NET types from the WSDL (WCF provides tools to do this), you could modify the
message using WCF itself. No reason to use a DSL.

[https://msdn.microsoft.com/en-
us/library/aa717047%28v=vs.110...](https://msdn.microsoft.com/en-
us/library/aa717047%28v=vs.110%29.aspx)

~~~
iamthepieman
Because I was frustrated and could not figure out how Microsoft wanted the
framework to be used. I was new to both WS and WCF at the time. getting WCF
configuration working seemed more like a voodoo incantation than any other
programming I've ever done.

And no I could not get .NET to generate types from the WSDL and I knew about
the tools provided for that. They didn't work and I wasted a lot of time on
them because everything I read said they should work.

I used a DSL because that's what I knew and because I had already wasted too
much time.

I've since learned to avoid situations like this but that's a whole 'nother
comment.

------
parasubvert
My tall tale version of WCF:

WCF (Indigo) was the attribute-oriented distributed object framework that
every COM developer dreamed of, co-designed by COM's rock star author, teacher
and orator Don Box, based on the successor to DCOM, which was WS-star.

Back in the late 90s, there were basically three religions out there: CORBA,
COM, and the nascent RESTafarians (REST wasn't coined until 2000, let's call
these people "XML over HTTP" friends). Then Java came out with EJB and native
CORBA, which everyone loved because it solved a problem with MTS/COM+ - it was
simpler (believe it or not), and actually had a notion of lifecycle that was
missing from most CORBA ORBs. Microsoft had to dodge this competitive threat,
and IBM had to find a way to make MQ important again. XML was co-opted to be
the new centre of everything, with the XML Infoset as the meta model for all
data description AND message exchange. Protocols were to be a thing of the
past, SOAP was protocol independent and WSDL described only message exchange
patterns over TCP, UDP, HTTP, JMS or MQ. Never mind that 99% used HTTP and
that all WSDL files were shared via HTTP GET. The church of WS* subsumed all
other religions from around 2002 through 2007, and WCF was to be the crowning
framework, destroying the ESB and the message broker the Microsoft Way.

Then around 2007 everyone woke up from their 15 year peyote trip and realized,
after tireless arguments from the RESTafarians, particularly Mark Baker, that
REST made sense and most of the specs in WS-* were reimplementations of what
already existed (WS-Addressing EPRs replaced URIs; WS-SecureConverstion was
multi-way SSL over XML exchanges), niche (WS-ReliableMessaging, WS-
AtomicTransaction) or hopeless (WS-Policy and children). All work ceased on
WS*, and people stopped worshipping communication protocols mostly. (except
REST, which became a bit inquisitorial for a few years now that it won, given
many years of being the laughing stock of billion dollar vendors)

REST on WCF was an afterthought that never really felt right. WCF was very
general and smart, RESTful HTTP is very specific and even dumb. Different
design for a different set of assumptions. That said I'm sure a lot can be
learned from its approach to composing a generic layered system of
communication capabilities.

------
reubenbond
What is a good alternative to WCF if I want Binary+TCP. I used WCF in the past
and didn't have trouble with it, but there is seething hatred for it in this
thread.

For the record, I eschewed XML configuration for code and instead of
supporting a range of protocols/transports, I used binary over TCP.

~~~
niaher
Would really like to know the same. I do get the hatred, but is there an
alternative to exposing your API via HTTP and TCP in a simple way?

------
ghuntley
On the topic of open-source check out [https://github.com/quozd/awesome-
dotnet](https://github.com/quozd/awesome-dotnet) which is a collection of
awesome open-source libraries, tools, frameworks and software for .NET.

~~~
runfaster2000
Here's another one: [https://github.com/Microsoft/dotnet/blob/master/dotnet-
devel...](https://github.com/Microsoft/dotnet/blob/master/dotnet-developer-
projects.md)

------
unwind
As a .Net outsider, it's not very inclusive of them to have an acronym in the
title like that.

I had to look down on the page to figure out that it means "Windows
Communication Foundation". It was not easy to quickly figure out what this
actually means, but I guess that's since it's highly technical and I'm not
immersed in the Microsoft/.Net talk.

~~~
vdnkh
I feel like MS is pretty good with their acronyms. Usually just Windows% or
Microsoft%. OSS, on the other hand, is a bit ridiculous.

 _It 's time [to] explain the meaning of "Hurd". "Hurd" stands for "Hird of
Unix-Replacing Daemons". And, then, "Hird" stands for "Hurd of Interfaces
Representing Depth". We have here, to my knowledge, the first software to be
named by a pair of mutually recursive acronyms._

~~~
bad_user
Hurd isn't ridiculous, I find it to be pretty cool and memorable. The only
problem is that the definition isn't tail recursive.

------
ChicagoDave
Never again will I work on WCF. I don't put the skill or experience on my
resume and I have refused several jobs where it was required. Too brittle,
complex, and with REST/OAuth 2, entirely unnecessary.

~~~
mdpopescu
I was with you right until OAuth :) That thing is not as bad as WCF but
still...

------
snarfy
10% coding, 90% XML configuration.

~~~
kabdib
... and nearly 100% impervious to debugging.

Which is what you _want_ in a communications library. But WCF is pretty
hermetic when Bad Shit happens (and it will).

------
josteink
Microsoft has open-sourced projects in the past and they have been given a
warm welcome and really flourished under the open-source banner. Examples are
ASP.Net, Roslyn and CoreClr.

As much as I applaud this move by Microsoft, WCF has a reputation for being a
terrible framework to work in the areas where it is most frequently employed,
and I doubt it will be given the same welcome.

------
omgtehlion
Nice.

WPF, please

~~~
Vitallium
Correct me if I'm wrong but Microsoft is not planning to make WPF and Windows
Forms Open Source.

~~~
ygra
Both are probably too entangled with Windows internals. Windows Forms is
essentially a wrapper around native GDI controls. WPF's rendering system is
quite intertwined with the DWM

It's much easier to open-source the things with fewer dependencies, such as
.NET Core, ASP.NET and other networking stuff. It's also invariably what
customers are likely to want to run on Azure (or elsewhere), just maybe not
with Windows underneath it.

For WPF I'm content with MS actually continuing development. WPF is the best
UI framework I've used so far with a lot of good ideas that have sadly been
ignored by most others. It's just sad that it got so little attention in
recent years.

~~~
achr2
I use WPF everyday and it has many great features. But sadly it was
conceptualized before many of the 'modern' and best features of .net. The
striking lack of type support (generics), and frankly broken separation
between form and function, makes it feel very clunky at times. Not to mention
that while data-binding is first class, the predominant MVVM pattern is sadly
bolted on. My last gripe is that in most WPF applications, the only reason the
application hangs is due to rendering performance - which is truly
unacceptable given every other part of my application can be multi-threaded or
async.

------
nesnej
For those who are looking for alternatives, you might be interested in WAMP
which reminds a bit WCF.

[http://wamp.ws/](http://wamp.ws/)

------
kylequest
Microsoft banned WCF inside Azure (their cloud platform), which says a lot
about it :) At least, that's what Mark Russinovich, CTO for Azure, says...

------
kabdib
"Over-designed and under-implemented"

WCF is one of Microsoft's many examples of this principle. Avoid this, the
solution hurts more than the problem.

------
talles
I'm so happy that I'm not the only one that _hates_ WCF.

Open sourcing an existing thing is never a bad thing though.

------
Pxtl
Every time I have to use WCF, I'm reminded that it stands for Windows
Configuration Fuck-up.

------
wtfwcfballball
Not once does the page spell out, WTF does WCF stand for?

~~~
dragonwriter
Windows Communication Framework.

------
UK-AL
One of the few ways to do high level IPC in .net.

------
iandanforth
Dear fellow nerds, please write out all acronyms the first time you use them
(TFTYUT), our nerd circles may not overlap. After TFTYUT you can use the nice
short version however you wish. Many thanks.

~~~
swalsh
I might be alone here, but when I do code reviews I always correct guys when
they use acronyms that are not "common knowledge". Things like ASN would be
allowed (i can google that easily), but if you're creating something new,
that's not a primary domain thing like FancyPowerControl, I don't want to see
FPC all over the code.

It may be persnickety, but it just really throws me off when authors create a
new acronym, and I have no idea what they're talking about.

Its all about the API for me. I don't want to see Device.FPC, when I have no
idea FPC is a thing. I want to see Device.Power

~~~
recursive
Hilariously, I've never heard of ASN, and googling turns up a dozen potential
meanings.

------
atlantic
Judging by the tone of some of the comments so far, and in keeping with the
spirit of the times, maybe we should include a trigger warning in the title of
any Microsoft-related news.

