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).
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.
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.
> 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.
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.
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.
> 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.
SOA in practice is not about the communication framework, it's about the delivery culture and discipline of using published interfaces of any sort in the first place. Amazon is perhaps the most successful example of a CEO-mandated SOA, they didn't really need something like WCF. Netflix used RESTful HTTP mostly for theirs.
Of course everything else you say about logging, changing, etc. is correct - operationalizing a SOA is hard, which is why we see so many frameworks focused on cloud microservices today.
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.
This. I've been using ServiceStack pre-commercial for over two years. The clean, flexible, RESTful routing and lean extensions are a breath of fresh air compared to previous frustrations with the hodge-podge WCF 'REST toolkit'. Mythz as an architect and maintainer is spot on.
I had thought that MS might be on it now with Web API, but your comment suggests not.
The only good thing about WCF is you can easily add a service reference in Visual Studio. Which lets you immediately proxy it to JSON with Web API: https://github.com/jpsingleton/Huxley :)
I used to use ServiceStack and it was great although I hear even StackExchange are moving away from it now (https://blog.stackoverflow.com/2015/05/stack-exchange-podcas...). BTW use the StackExchange Redis client over the ServiceStack one as it's not properly thread safe.
Which works very much like a DB Connection, where the Connection Factory is thread-safe (and what's used to resolve connections) whilst the DB Connection instance it returns are not.
Sorry, I know you worked hard on it but this comes from real experience. We had an absolute nightmare debugging strange issues in the cache and traced it to this. Probably an older version though.
Each threading issue reported ended up being traced back to sharing a RedisClient instance across multiple threads, e.g. by using a static RedisClient instance, registering RedisClient in IOC, etc - i.e. instead of using one of the ThreadSafe connection factories. If you have any repro showing any multi-threading issues with proper usage we'd love to hear about it (https://github.com/ServiceStack/Issues).
I really liked Webservices in ASP.net when they were new, really easy to set up and you just had to add an attribute to the methods you wanted to expose. With WCF they went too far in covering all enterprise scenarios.
It would have been better if they kept and maintained a streamlined alternative. Forcing everyone to deal with the complexities of WCF isn't developer friendly.
This is a common anti-pattern in frameworks where they grow until they are a kitchen sink monster instead of splitting of into different frameworks streamlined for different purposes.
I agree with the gist, but I'm curious as to why you would use WCF when there were simpler existing solutions (eg. Web Services)? If you simplified WCF to decoration via attributes, what do you gain over ASP.net Web Services?
as long as you don't need any of the features of WCF you shouldn't of course (though I think webservices become an obsolete technology).
As soon as you run into edge-cases with authentication, compression, binary formats etc you'd have to use WCF. I think many use WCF "just in case" they need those features
Considering I've went from http to tcp services a number of times for improved performance, and you can simplify WCF clients a LOT via convention, it really isn't that bad...
When you are building WCF services and clients, in conjuction with a DI/IoC framework it can work REALLY well... I wrote an extension for MS-Unity that would generate service clients from a simple app settings string for the resource endpoint... that would automagically create a generic client on the fly in production.
For the server-side mounts, I had utility methods to mount several services into a single MVC web application, and it was just about seamless... for the project there was a base interfaces project that defined the services, so that the client and implementation were abstracted from eachother. It really was pretty slick in the end, and far from the default visual studio implementation.
I've also used WCF services as a message bus between a Flash/Flex simulation front end, and a connected backend service for that simulation instance. It wasn't bad.
That said, I much prefer to use node.js and simple JSON RPC and/or REST services these days over http or websockets (socket.io/sockjs), depending on what is pragmatic. It wasn't an option 8-9 years ago.
>If you want to make a RESTful API with .NET
WCF is overengineered for this, but this doesn't necessary means that WCF sucks.
Right tool for the right job.
> design your messages first and then figure out what the URLs should look like.
This is exactly what WCF let me do though and I wasn't limited to using HTTP like the others you listed. I was able to use a full duplex binary tcp channel instead.
I thought WCF was more hassle than it was worth. Then I got a massive performance boost from switching to the TCP transport with a quick configuration change ...and had fallback to HTTP after writing a few lines of code. Making the transport orthogonal to other concerns is a big win.
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.
WCF is passable iff both your sides are .NET - in which case it is an overkill, slow and unneededly complex. If your other endpoint is not .NET, it's all of that and also horribly broken.
Have enumerations somewhere? WCF will encode them as integers. Have or need a date/time value in a format that isn't what WCF generates or expects - e.g. JSON Date() expressions? Doable, but error prone, slow and unintuitive (and ... In that case - why use WCF at all?)
WTF would have been a better name for this library.
I remember so much pain trying to get a .NET WCF and Java SOAP service to work together when they should have been compatible. This is an amusing read: http://harmful.cat-v.org/software/xml/soap/simple :)
The UK National Rail API is a WCF SOAP endpoint so I wrote this open source proxy with Web API to make it easier for non-.NET developers more familiar with restful JSON: https://github.com/jpsingleton/Huxley
But e.g. Enum Direction { East, West, North, South };
Put that as a field in a structure that's sent/received through WCF; on JSON it will encode as numbers, regardless on any annotation you put. On XML iirc too - though I don't remember for sure. Want them as strings? You have to encode/decode yourself. But if you use .NET on both sides , you wouldn't notice unless you sniff the connection - until you change the enumeration order, for example, and all help breaks loose. Which is to be expected of a binary protocol, but completely unexpected for verbose text formats like JSON or XML.
WCF's REST is the ugliest implementation of HTTP/REST I've seen from any framework, whilst its RPC method signatures, SOAP format and code-gen client proxies provide one of the most fragile combination of technologies used in web services today: http://www.infoq.com/articles/interview-servicestack
Web API is the easiest thing you can use. I switching from desktop programming to web and creating restful services in web api allowed me to do a lot with little and also teach me a thing or two about REST. I highly recommend it.
Or if you want to flow delegated credentials, or use cross-system transactions. The enterprise stuff actually does something that can be useful inside a company.
Also, the major advantage of SOAP is that at least it has a service description. So generating clients is an easy one step process (and, having shipped such a service, when works on many platforms and languages reasonably well). All these new HTTP/JSON APIs require custom clients each time. Until they invent WSDL for such services... And full circle. Except JSON instead of XML, so it's totally OK.
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.
> 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.
While WCF supports WS-* and is in large part organized around it, some of the complexity isn't "because WS-", its "because WCF is a higher-level abstraction that supports, among other things, WS-* ".
I mean, you can apply all that overengineered configuration to build REST services with WCF, too. You probably don't want to (unless you are already heavily invested in WCF), but you can.
>...its "because WCF is a higher-level abstraction that supports, among other things, WS-* "
And it fails spectacularly. I mean, _it works_, but it's a disaster to work with and write software against.
The entire abstraction is leaking profusely, all precisely "because WS-*". Who in their right mind will attempt to establish a family of standards for "transport-agnostic" communication, routing, serialization and whatnot when realistically 99% of the time HTTPS is all you ever need?
> And it fails spectacularly. I mean, _it works_, but it's a disaster to work with and write software against.
Can you give an example of how it's a disaster? I'm genuinely curious because I've had to use it for at least 5 years (I still support 1 WCF solution) and this was never my experience.
Have you used WCF talking to non-WCF WS-* things, or just WCF to WCF? My experience was that the latter (mostly) just worked but interop was somewhat of a nightmare, making the whole WS-* thing somewhat pointless. It wasn't really WCF's fault; just that no two WS-* implementations actually implemented things identically.
I've used it with all sorts of backends and clients. And you're right - in most cases it wasn't WCF's fault. Which is why I'm curious about why OP blames WCF.
> WCF is one of the most over-engineered frameworks I've encountered so far
This may be true to an extent, but rarely will you ever need to delve into that level of minutiae (which itself is a consequence of WS-*...). I've set up custom endpoints, but that's comparable to setting up custom logging with Log4J. I've extended/written custom Message Inspectors to log/analyze/manipulate data, but that was hardly complex as well, and comparable to what you would need to do in any other environment but without support of the framework.
For me the most frustrating thing working with WCF was probably correctly configuring Windows authentication/authorization simply because there are so many different ways things can fail with similar error messages. Everything else you mentioned is stuff that you rarely need to consider.
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.
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.
A lot of the complexity is baked into the WS standards of which WCF is only an implementation. So until new standards are rolled out there is a limit to how much clean up can happen.
Then the other thing is the fundamental concept of WCF requires a lot of inherent complexity.
There is still a good amount of complex for complex's sake that could be cleaned up so hopefully that happens.
But its been said WCF is pretty much dead so not sure how much effort will go into it.
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.
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.
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.
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.
Yeah I am not so sure I would serve content using Katana. I am using it to horizontally scale out data services used by clients around the world, hosted in Azure. It's simple to deploy and manage. I also don't have to mess with IIS, which is always a plus given how few admin resources we have to maintain our environment.
Katana can host your services for you outside of IIS. You can use Web API and Nancy with it. I am sure someone has figured out how to setup servicestack as well.
Katana/OWIN provides a pipeline for hosting .NET web[sites|services] without IIS. This is another direction .NET is heading, no more IIS shackling (if you so choose)
Using the OWIN HttpListener rather than relying on IIS has been a godsend for many of the applications that we develop. IIS simply has too many knobs that users can twiddle and break our applications. Running a webserver out of a Windows service, with everything sandboxed and tuned to the needs of our application is much simpler.
Plus, no need to rely on Powershell scripts, or god forbid, the user, to get the correct set of IIS features installed has made deployment of our apps infinitely simpler.
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.
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.
WCF is ridiculously complex, has poor testing options and troubleshooting deep issues basically requires turning on logging and loading a massive data dump into a reader just to get some kind of generic error.
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.
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.
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.
On the topic of open-source check out https://github.com/quozd/awesome-dotnet which is a collection of awesome open-source libraries, tools, frameworks and software for .NET.
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.
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.
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.
I work in risk management for a financial institution. And although I'm on the "business" side of things, I do have to develop a lot of applications for own quant finance work. And frankly, to my team subsets of WCF (like for example, DataContracts) are becoming invaluable.
Most of the comments I see here mention a JSON API or some other "REST" architecture suitable for a web app as a better alternative. This gives off an extreme "let them eat cake" kind of vibe. Seriously, there are other kind of systems than web apps. Having a way to strictly define your interfaces and your data flows, having an ability to quickly validate data that you get and communicate which kind of data you want is extremely important in situations where correctness of the result comes first, and you don't have control over the whole system landscape.
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.
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.
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.
Entirely true. Still, seems like if they were to open-source WPF, the Mono community would have an interest in trying to abstract out the DirectX dependencies and making it run on OpenGL. Shame we'll probably never see it happen - it would be great to see a true cross-platform GUI toolkit for .NET that's not GTK.
During the talk at Build on WPF there were some slight hints that it may be open sourced at some point in the future, I'm not holding my breath though.
I'm always surprised by the people asking "bring VB6 back". I'd like to know why - is it because you're stuck maintaining VB6 applications that can't be/haven't been updated to VB.net or C#? I used VB6 extensively back in the day, and I am very glad indeed that it's now dead.
It is ridiculously easy to create simple GUI apps with it, its limitations force you to write straightforward code (otherwise it becomes too much of a hassle and you go to another language) and provides a very good debugging environment which allow you to inspect and modify a program as it is running in a graphical way.
It is basically an extremely simple scripting language attached to a GUI designer (literally, originally VB was supposed to allow different languages to be used with it, but the feature was dropped).
Also it is instant fast on modern hardware.
Most people who have a grudge against VB1-6 have it either because they have no idea what they were talking about and are just parroting others (to be honest, i did that at the past), or were exposed to it via a project that abused it in ways that it wasn't meant to be (ab)used.
A while ago i made this little sprite editor in VB5:
It isn't anything special but it is actually quite useful if you're making low-res pixelart 2D games and personally i had fun making it (the first version also took me only a weekend although i added a few features since then).
Having said that, i do not expect Microsoft to bring back VB6 nor release the source code since now they seem to focus away from the desktop and VB6 is a full 1005 desktop technology.
To my mind, all of the points you listed as an advantage you can also find with C#/VB.net using WinForms. I've also never found WinForms or even WPF (most of the time) to be sluggish on even reasonably modern hardware.
What specifically do you find easier in VB6 than VB.net/C# when writing desktop apps, in particular in relation to WinForms?
You say "inspect and modify a program as it is running in a graphical way" - do you mean that with VB6 you could alter the UI as the application was running? If so, that's something I don't remember but I agree it could be very handy!
I've mostly had coworkers that had fond memories of VB6. Personally, compared to what we have now, I think it sucks. I'm no parroting. I suppose there's no way for me to know whether I "have any idea what I'm talking about". The language itself is terribly constraining. No try/catch. No generics. Crazy 1-based collections. No type-safe lists, just fixed size arrays. No function references. And so on.
Fun trivia: The first version of UnrealEd, the editor for the Unreal Engine 1 (used in Unreal, Wheel of Time, Rune, Deus Ex, UT99, Clive Barker's Undying etc.), was written in VB (of course, it used the renderer via interop).
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.
> 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
I think you've found your problem.
I'm pretty sure everyone has had to deal with alien legacy systems at some point in their lives. It just goes with the territory. I have yet to come across a technology to that can handle all exceptions and edge cases.
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.
Actually, given the disconnect with how poorly Java (and PHP) services are for defining their child types ("Object" should never be a type exposed in the wsdl), I've found that creating a shim service in Node.js to connect to the Java/PHP webservices to funnel requests into something that can be better typed against works... I don't like doing it, but it works.
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.
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
> please write out all acronyms the first time you use them
Like any other writing, it's just about knowing your audience.
I mean, are you really going to write "HN (Hacker News)", "YC (Y Combinator)", "HTTP (Hyper-Text Transfer Protocol)", etc. every single time you use those in a comment here?
Bits of every domain are obscure to someone. But it seems to me that the only domain for which use of acronyms in article titles ever seems to provoke this level of irritation is Microsoft's. Makes me suspect that this particular debate is really just a proxy for a different argument altogether.
Is this really the case? I've been using it since it's inception (never used "Indigo" in production). At the time it was a godsend because our company was moving to a SOA (ahh... the dark ages) using Oracle Fusion Middleware, and judging by the job postings over the years I suspect many other non-Java/Oracle houses also adopted WCF.
I did not realize it was considered an obscure technology.
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.
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:
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).