Is .NET Remoting really deprecated?

Question

Everyone is saying how .NET Remoting is being replaced by WCF, but I'm wondering just how accurate that is. I haven't seen any official word that Remoting is being deprecated, and it seems to me there are certainly scenarios where Remoting makes more sense than WCF. None of the Remoting-related objects or methods have been deprecated, even in version 4.0 of the framework. It is also my understanding that System.AddIn in the 3.5 and 4.0 frameworks use Remoting.

Does anyone have any official word to the contrary?

In the article, Choosing Communication Options in .NET (for 3.0, as that's the latest version of that article), it states:

8 Cross-application domain communications

If you need to support communication between objects in different application domains within the same process, you must use .NET remoting.

Now, that, of course, isn't accurate, as WCF can certainly be used to cross appdomain boundaries, but is it giving the official recommendation for that scenario?

Update: I sent Clemens Vasters (who was on the team that owns Remoting and WCF) this question:

Clemens, I understand you're on the team that owns both remoting and wcf, and I have a couple of questions that I believe I need to go to the source for.

First, I have a question about whether remoting is going away. Specifically, we have a rather large application that uses remoting extensively for in-process cross-appdomain communication, and I was wondering if this usage of remoting is considered "legacy". If so, will AppDomain.CreateInstance and friends be replaced with something else?

This is his reply:

Remoting is part of the .Net Framework and as such it isn't going away. COM has been in Windows since Windows NT 3.5/Windows 95 and hasn't gone away and I don't see that going away anytime soon, either.

That said, there is very minimal development investment going into Remoting. WCF is the successor of Remoting and supplants COM/DCOM for managed code.

For in-process, cross-appdomain communication Remoting is the CLR's native way of communicating. If you are seeing performance issues pumping larger amounts of data or very many messages in short time, you should take a serious look at WCF and the NetNamedPipeBinding.

Ers

See #1295853 for a question about why WCF is so much slower than Remoting in my specific situation. – Ers

Remoting is intrinsic to .NET, and details of the role it plays and how it works may be found in Essential .NET by Don Box and Chris Sells. However, it falls apart when inter-component communications is unreliable or slow, and practically all transports - even a gigabit LAN - are unreliable and slow compared to in-process messaging. When people talk about WCF being slow, they are usually thinking of web services. Web services are too slow if you try to use them for in-process comms. However, they are designed to tolerate slow and unreliable connections and serve well in these conditions. – Pietrek

@Peter: thanks for the information, but a couple of your assumptions are completely wrong. One, that remoting is slow or unreliable. It's not. It's very fast, and very reliable (over reliable channels, of course). Another is that "web services" (whatever that means) are slow. They're not. Of course, anything in-process is going to be much faster than anything over the network, but that's not at all what this question is about... – Ers

now wcf is nearly dead and microsoft recommends grpc... – Divisor

Answer 1

Calling it a legacy technology is a more accurate description.

http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx

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

Update: WCF doesn't distinguish between inter/intra/process/inter/intra-appdomain. If you are using single machine communication in WCF you use named pipes- using it should give good performance in virtually all realistic scenarios.

For a performance comparison of various distributed communication technologies see here.

Dynatron

Isn't that article referring specifically to using remoting in interprocess communication? It seems to me that remoting still has a place in cross-appdomain communication (AppDomain.CreateInstanceFromAndUnwrap and friends). – Ers

Yes it is. If these classes had been "deprecated", they would have the ObsoleteAttribute applied to them- msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx. – Dynatron

@Mark, @RichardOD: The article is the head article on .NET Remoting. It does not just refer to inter process communication. Also, the fact that the ObsoleteAttribute is not on them in .NET 3.5 means nothing, since the decision to announce Remoting (and ASMX web services) as "legacy" was made post .NET 3.5 RTM. – Masterstroke

@John: They're not marked [Obsolete] in 4.0 either (at least not yet). – Ers

@Mark: you mean 4.0 beta 1. – Masterstroke

@John- do you have any source for this information about when the "legacy" status was announced (apart from your MSN space)? Personally I stopped using ASMX/Remoting for interprocess communication ages ago as the many advantages of WCF were more than apparent to me. – Dynatron

I don't have anything public. I sent an email to a contact at Microsoft CSD when I noticed this. I had been pestering him frequently about the messaging around WCF vs. ASMX for a couple of years. I just checked my email, and it seems I sent the message on July 3, 2009. – Masterstroke

For internal development I actually dislike WCF as it's more of a pain in the butt than Remoting to keep the client code updated. I started my project with WCF like "whoa, this is the latest and greatest" and realized about the third time I had to delete and recreate a service reference that it was completely stupid compared to Remoting at least in terms of speed of development of an internal service architecture. I viewed it as a step backwards. – Latoyia

Answer 2

Yes. Remoting is deprecated...and it's official from Microsoft. Here's the link:

.NET Remoting

The first line in the article says in bold:

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

I thought the verbiage was 'deprecated' but apparently they refer to it as 'legacy'

Danaides

IMO 'deprecated' is stronger than 'legacy': 'legacy' means "don't start", and deprecated means "if you've already started, stop now, because it may be removed entirely in future versions". – Whereas

So, would it be accurate to say it's been deprecated for cross-application communication, but not for cross-appdomain communication? – Ers

@Mark: I don't read it that way. WCF seems as applicable for intra-process communication as is Remoting (see the NetNamedPipeBinding in WCF). – Multitudinous

@Michael: Just because WCF is applicable doesn't mean Remoting is deprecated, and NetNamedPipeBinding is just as useful for inter-process as it is for intra-process. Also, my own tests show that Remoting (for the scenario I'm testing) is an order of magnitude faster than even NetNamedPipeBinding. – Ers

@Mark: Regardless, Remoting is deprecated. @ChrisW: I doubt that Remoting will be removed in the near term, but you can expect fewer bug fixes, if any, and less support, if any. – Masterstroke

@Ers - I was speaking to the article referenced in this answer. The article refers to .NET Remoting as "legacy" and "not recommended for new development". I was making the point that there's no reason to believe that that verbiage excludes the intra-application scenario. – Multitudinous

@Ers - what is your real question? Remoting is considered legacy technology. It sounds like you don't wish that to be true. You may have good reasons, but that doesn't really speak to Microsoft's current recommendations. – Multitudinous

@Michael: Just what I asked. If people want to say it's "deprecated", then is there any official word to back that up? It's a whole other question, I guess, whether "deprecated" and "legacy" are synonyms ;) – Ers

@Mark: in this case, you'll also want an official definition of "deprecated", and I don't know where you'll find that. Isn't "legacy" bad enough? They clearly don't want you to develop new code with Remoting. Are you looking for an excuse to do it anyway? – Masterstroke

@John: I guess I am. I'm specifically doing in-process cross-appdomain communication (using AppDomain.CreateInstanceFromAndUnwrap and friends), and I don't see a way to do this as cleanly (or as high-performance) using WCF. I'm happy to use WCF instead (I use it a lot in other scenarios), but for this I'm having trouble getting it working the way I want. I'll post another question about that specific scenario. – Ers

Answer 3

If you like to migrate to .NET Core you have to find another solution for Remoting anyway:

.NET Remoting was identified as a problematic architecture. It's used for cross-AppDomain communication, which is no longer supported. Also, Remoting requires runtime support, which is expensive to maintain. For these reasons, .NET Remoting isn't supported on .NET Core, and we don't plan on adding support for it in the future.

Source: https://learn.microsoft.com/en-us/dotnet/core/porting/libraries#remoting

Masorete

Here you can find a discussion about what alternatives are available in .NET Core: github.com/dotnet/corefx/issues/18394 – Masorete

Mentioned also here: learn.microsoft.com/en-us/dotnet/core/porting/… – Masorete

Answer 4

Clemens Vasters, the Technical Lead for the Microsoft .NET Service Bus (that means both Remoting as well as WCF) talks about WCF vs. Remoting in this forum post. To summarize the post he ends up recommending WCF over Remoting.

I'm not sure if .NET 4.0 uses remoting internally but you could try sending Clemens the question... I'm sure he knows the answer.

Tirzah

A Microsoft employee recommending use of the new shiny-new-incompatible-with-everything-else method over any form of standard? Shocking. – Elastance

In what way is WCF not compatible with everything else? And Remoting was compatible with what? – Masterstroke

If you're looking for compatibility, WCF is the -only- choice (except asmx, of course, but that's "legacy" as well). Remoting was -never- suitable for scenarios where compatibility was a requirement. – Ers

I took your suggestion and asked Clemens. His reply: "Remoting is part of the .Net Framework and as such it isn't going away... For in-process, cross-appdomain communication Remoting is the CLR's native way of communicating." – Ers

He goes on to say that you should "take a serious look at WCF and the NetNamedPipeBinding." – Masterstroke

Answer 5

I think that now (2015) it's quite clear even for cross application domains: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Remoting Cross AppDomains 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).

Then WCF should be used for cross application domains too.

Mcgowan

Seven years on and WCF in turn has been abandoned because netcore is cross platform. Apparently WCF is a Windows thing, although so far as I can see they could fix that by renaming it MCF. – Pietrek