81–90 of 149 posts
Earlier quoted context omitted.
Oh come on. WCF is pretty obscure. .NET is pretty unknown to many HN readers, and even within .NET WCF is not very widely used.
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.
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 ove…
I've been there and this tool is invaluable: http://www.soapui.org/ That and wireshark, and netmon. OK, I need to stop now or the repressed memories will come back. :)
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.
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".…
I had thought that MS might be on it now with Web API, but your comment suggests not.
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.
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.
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...
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".…
IIRC WCF was used in CSLA to allow 2-tier apps to turn into 3-tier apps with just a config change. Probably the only good thing about it.
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".…
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.
WCF is one of Microsoft's many examples of this principle. Avoid this, the solution hurts more than the problem.
10% coding, 90% XML configuration.
Which is what you want in a communications library. But WCF is pretty hermetic when Bad Shit happens (and it will).
Earlier quoted context omitted.
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 ).
Earlier quoted context omitted.
I've been there and this tool is invaluable: http://www.soapui.org/ That and wireshark, and netmon. OK, I need to stop now or the repressed memories will come back. :)
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.