What are the benefits of migrating our application over to WCF as opposed to continuing to use .NET Remoting?

Question

Alright, so I've asked several questions on StackOverflow about .NET Remoting, and there is always at least one person who just has to chime in, ".NET Remoting is deprecated, use WCF instead." I understand that it's deprecated and there is no guarantee of future support with new versions of the .NET Framework. But what are some other good reasons we would want to move over to WCF? I have seen a few mostly minor annoyances with .NET Remoting, however, this is not enough to change the minds the powers that be who believe firmly in "if it ain't broke, don't fix it". At this time, the only reason that attitude will change is if .NET Remoting is removed from a future version of the .NET Framework, so who knows how long that will be?

Does anybody have any insight as why exactly WCF is "better" than .NET Remoting, or why Remoting is inferior to WCF? What are the pros and cons of each technology? Are there additional things you can do with WCF and not with Remoting?

I mean, it would be great if I could convince them to let us migrate our software over to WCF just to allow a configurable TcpChannel timeout to be set on the client side (this seems to have been broken for a while, no matter what steps or troubleshooting I try), and when this happens, it makes our software look like absolute shite.

Thanks in advance for helping to shed some light on this.

Shechem

Answer 1

There are plenty of reasons to ditch remoting; a few might include:

• lack of transport flexibility
• versioning requirements are huge pain
• platform dependent (no sensible chance of cross-platform usage)
• no chance of usage from the growing mobile market
• lack of future development: whatever feature you want added - it won't be

however, I would disagree that WCF is the automatic replacement; WCF itself is a pretty versatile tool, but can be pretty complex, and has restrictions of its own. I haven't used it myself, but I have seen lots of praise for Service Stack, essentially with users describing it as "WCF done right", i.e. the good bits of WCF, without the pain points. However, there are plenty of other options too. One nice thing about the idea of Service Stack, though, is that it iterates pretty quickly, and if it lacks something you want you can change it.

Tosch

Service Stack is definitely piquing my interest, I'll have to look into it more in depth once I get some extra time on my hands. It would have to run alongside .NET Remoting for legacy client access so as long as it can do that, I think I can dig on this. I've also been told that a .NET Remoting client can be configured to connect to a WCF service. I've heard of .NET Remoting and WCF running side by side, but I haven't been able to confirm if a Remoting client can interface with WCF. Is this true? If it is, it would be interesting to find out if Service Stack supports this as well. – Shechem

Answer 2

.NET Remoting is now a legacy technology, quoted from MSDN:

This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).

And here is a performance comparison between WCF and .NET Remoting done in 2007: http://msdn.microsoft.com/en-us/library/bb310550.aspx

To summarize the results, WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting.

So I guess speed is a good reason to drop .NET Remoting.

Welch

Your first point is addressed by the asker in the question: "I understand that it's deprecated and there is no guarantee of future support with new versions of the .NET Framework". Your performance reference is good though. – Cholesterol

Very interesting. I had heard WCF was faster than .NET Remoting, but 25% is quite a bit faster than I thought it would have been. – Shechem

Answer 3

While the given reasons are probably the driving considerations there are other non-trivial reasons:

• Transport independence
• IDE tooling
• Ease of testing
• Maintainability

When you use WCF you can change transport merely by editing your config file. This can be very handy when some sanctimonious system admin won't open a port and you need to use HTTP on port 80 to get through the corporate firewall.

The WCF tooling in Visual Studio is phenomenal. The hardest part is figuring out the URL you need. After that it's just point and click for code generation. There are one or two gotchas with serialisation of collections but broadly speaking if you tell both ends to use arrays it will just plain work. If you need a collection at the destination you can always construct one around the received array, and since LINQ will happily operate on arrays you can fold this into other transformations.

I'm not sure what Stephan P means by pain points. Editing the config can be tricky but Microsoft provides an excellent GUI tool that takes all the guesswork out of it by providing a full tree of options yet generating a sparse config file.

WCF services are easy to test because they have a published interface to which you can connect a test harness. This is more a virtue of SoA in general rather than WCF in particular, but it's still desirable.

WCF makes things a great deal simpler in my code, since neither application nor service is polluted with "routing" code (to determine what ought to process the message content); it looks like simple method calls or implementations. I mostly use WCF as a wrapper for MSMQ, and the only visible consequence of the transport selection is that these method calls must all be void functions because it's a OneWay transport. But that's hardly surprising when the point was persistent queueing.

This all speaks to maintainability. Even for in-house applications, maintenance is a dominant cost, and when you're supporting your software at customer sites poor maintainability can be crippling.

Then there's interoperability with otherwise incompatible platforms. In this case I'm thinking of using HTTP/XML or HTTP/JSON to provide service to web apps written in (eg) PHP.

Going the other way isn't quite so easy but it's fairly straightforward.

Columbia

Well, you can just change the config file in .NET Remoting as well to change the transport, at least in the way we have our application configured. I guess one of the things that I do like about .NET Remoting is that it's fairly simple to work with, WCF is a bit more complex, and is also way overkill for our application, which is just a simple call to a remote method and see what the return code is. – Shechem

I guess it comes down to familiarity. For me, setting up WCF for a simple call to a remote method is a couple of minutes of point and click. I get the distinct impression I've totally failed to sell this as an improvement on your current situation. – Columbia

Answer 4

I give points for WCF with respect to logging and security.

Logging WCF has an integrated Logging mechanism that helps you log traces that become a boon during maintanence. In other technologies, developer has to do some work to achieve this but in WCF, all that we have to do is to enable trace by changing the config file and WCF starts providing traces for you.

Security Security mechanism in WCF is fairly simple and out of box when you look from the implementors perspective but is very robust and highly secure. The best part is that for the highy used and recommended bindings, WCF provides default security which can be trusted to the core. The message security on WSHTTPbinding is an example on these lines.

.NET Framework remoting does not do authentication or encryption by default. Therefore, it is recommended that you take all necessary steps to make certain of the identity of clients or servers before interacting with them remotely

Moreover WCF is an framework to develop Service Oriented applications under microsoft platform mixing both message and rpc style of programming. Which was not in the remoting. Remoting is basically oriented to rpc only.

Motorbus