O .NET Remoting está realmente obsoleto?

95

Todo mundo está dizendo como o .NET Remoting está sendo substituído pelo WCF, mas estou me perguntando o quão preciso isso é. Eu não vi nenhuma palavra oficial que o Remoting está sendo preterido, e parece-me que certamente existem cenários onde o Remoting faz mais sentido do que o WCF. Nenhum dos objetos ou métodos relacionados ao Remoting se tornou obsoleto, mesmo na versão 4.0 do framework. Também é meu entendimento que System.AddIn nas estruturas 3.5 e 4.0 usam Remoting.

Alguém tem alguma palavra oficial em contrário?

No artigo, Escolhendo opções de comunicação em .NET (para 3.0, já que é a versão mais recente desse artigo), ele afirma:

8 Comunicações de domínio entre aplicativos

Se você precisar oferecer suporte à comunicação entre objetos em diferentes domínios de aplicativo dentro do mesmo processo, deverá usar o .NET Remoting.

Agora, isso, é claro, não é preciso, já que o WCF pode certamente ser usado para cruzar os limites do appdomain, mas está dando a recomendação oficial para esse cenário?

Atualização: Enviei a Clemens Vasters (que fazia parte da equipe proprietária do Remoting e WCF) esta pergunta:

Clemens, entendo que você está na equipe que controla o remoting e o wcf, e tenho algumas perguntas que acho que devo responder à fonte.

Em primeiro lugar, tenho uma pergunta sobre se a comunicação remota está indo embora. Especificamente, temos um aplicativo bastante grande que usa remoting extensivamente para comunicação entre appdomain em processo, e eu queria saber se esse uso de remoting é considerado "legado". Em caso afirmativo, AppDomain.CreateInstance e amigos serão substituídos por outra coisa?

Esta é a resposta dele:

Remoting é parte do .Net Framework e, como tal, não vai desaparecer. COM está no Windows desde o Windows NT 3.5 / Windows 95 e não foi embora, e também não vejo isso em breve.

Dito isso, há um investimento mínimo de desenvolvimento para o Remoting. WCF é o sucessor do Remoting e suplanta COM / DCOM para código gerenciado.

Para comunicação em processo, entre appdomain O Remoting é a forma nativa de comunicação do CLR. Se você estiver vendo problemas de desempenho bombeando grandes quantidades de dados ou muitas mensagens em pouco tempo, você deve dar uma olhada séria no WCF e no NetNamedPipeBinding.

.net wcf remoting

— Marca
fonte

1

Consulte stackoverflow.com/questions/1295353/… para uma pergunta sobre por que o WCF é tão mais lento do que o Remoting em minha situação específica.

— Marcos

1

O remoting é intrínseco ao .NET, e os detalhes da função que ele desempenha e como funciona podem ser encontrados em Essential .NET de Don Box e Chris Sells. No entanto, ele falha quando as comunicações entre componentes não são confiáveis ou são lentas, e praticamente todos os transportes - até mesmo uma LAN gigabit - não são confiáveis e são lentos em comparação com as mensagens em processo. Quando as pessoas falam que o WCF é lento, geralmente estão pensando em serviços da web. Os serviços da Web são muito lentos se você tentar usá-los para comunicações em processo. No entanto, eles são projetados para tolerar conexões lentas e não confiáveis e funcionam bem nessas condições.

— Peter Wone

3

@Peter: obrigado pela informação, mas algumas de suas suposições estão completamente erradas. Um, que a comunicação remota é lenta ou não confiável. Não é. É muito rápido e muito confiável (em canais confiáveis, é claro). Outra é que os "serviços da web" (o que quer que isso signifique) são lentos. Eles não são. Obviamente, qualquer coisa em processo será muito mais rápido do que qualquer coisa na rede, mas não é disso que se trata ...

— Marcos

54

Chamar isso de tecnologia legada é uma descrição mais precisa.

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

Este tópico é específico para uma tecnologia legada mantida para compatibilidade com versões anteriores com aplicativos existentes e não é recomendado para novos desenvolvimentos. Os aplicativos distribuídos agora devem ser desenvolvidos usando o Windows Communication Foundation (WCF).

Atualização: o WCF não distingue entre inter / intra / processo / inter / intra-appdomain. Se você estiver usando comunicação de máquina única no WCF, use pipes nomeados - usá-lo deve fornecer um bom desempenho em praticamente todos os cenários realistas.

Para uma comparação de desempenho de várias tecnologias de comunicação distribuída, clique aqui .

— RichardOD
fonte

Esse artigo não se refere especificamente ao uso de remoting na comunicação entre processos? Parece-me que o remoting ainda tem um lugar na comunicação entre appdomain (AppDomain.CreateInstanceFromAndUnwrap e amigos).

— Marcos

Sim, ele é. Se essas classes tivessem sido "reprovadas", elas teriam o ObsoleteAttribute aplicado a elas - msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx .

— RichardOD

2

@Mark, @RichardOD: O artigo é o artigo principal sobre .NET Remoting. Não se refere apenas à comunicação entre processos. Além disso, o fato de o ObsoleteAttribute não estar neles no .NET 3.5 não significa nada, já que a decisão de anunciar o Remoting (e os serviços da Web ASMX) como "legado" foi feita após o .NET 3.5 RTM.

— John Saunders de

@John: Eles também não estão marcados como [Obsoletos] no 4.0 (pelo menos ainda não).

— Marcos

@Mark: você quer dizer 4.0 beta 1.

— John Saunders

11

Sim. Remoting está obsoleto ... e é oficial da Microsoft. Aqui está o link:

.NET Remoting

A primeira linha do artigo diz em negrito:

Este tópico é específico para uma tecnologia legada mantida para compatibilidade com versões anteriores com aplicativos existentes e não é recomendado para novos desenvolvimentos. Os aplicativos distribuídos agora devem ser desenvolvidos usando o Windows Communication Foundation (WCF).

Achei que a verborragia era "obsoleta", mas aparentemente eles se referem a ela como "legado"

— Justin Niessner
fonte

21

IMO 'obsoleto' é mais forte do que 'legado': 'legado' significa "não iniciar" e obsoleto significa "se você já começou, pare agora, porque ele pode ser removido totalmente em versões futuras".

— ChrisW

1

@Mark: Eu não leio dessa forma. O WCF parece ser aplicável para comunicação dentro do processo, assim como o Remoting (consulte NetNamedPipeBinding no WCF).

— Michael Petrotta de

1

@Mark: Independentemente disso, o Remoting está obsoleto. @ChrisW: Duvido que o Remoting seja removido no curto prazo, mas você pode esperar menos correções de bugs, se houver, e menos suporte, se houver.

— John Saunders de

1

@Mark - qual é a sua verdadeira pergunta? Remoting é considerado tecnologia legada. Parece que você não deseja que isso seja verdade. Você pode ter bons motivos, mas isso não corresponde às recomendações atuais da Microsoft.

— Michael Petrotta

1

@John: Acho que sim. Estou especificamente fazendo comunicação entre appdomain em processo (usando AppDomain.CreateInstanceFromAndUnwrap e amigos) e não vejo uma maneira de fazer isso de forma limpa (ou de alto desempenho) usando o WCF. Estou feliz em usar o WCF (eu o uso muito em outros cenários), mas para isso estou tendo problemas para fazê-lo funcionar da maneira que desejo. Vou postar outra pergunta sobre esse cenário específico.

— Marcos

6

Se você gostaria de migrar para o .NET Core, você precisa encontrar outra solução para Remoting de qualquer maneira:

.NET Remoting foi identificado como uma arquitetura problemática. É usado para comunicação entre AppDomain, que não é mais compatível. Além disso, o Remoting requer suporte de tempo de execução, cuja manutenção é cara. Por esses motivos, o .NET Remoting não tem suporte no .NET Core e não planejamos adicionar suporte para ele no futuro.

Fonte: https://docs.microsoft.com/en-us/dotnet/core/porting/libraries#remoting

— Jean-Claude
fonte

1

Aqui você pode encontrar uma discussão sobre quais alternativas estão disponíveis no .NET Core: github.com/dotnet/corefx/issues/18394

— Jean-Claude

Mencionado também aqui: docs.microsoft.com/en-us/dotnet/core/porting/…

— Jean-Claude

2

Clemens Vasters, o líder técnico do Microsoft .NET Service Bus (que significa tanto Remoting quanto WCF) fala sobre WCF vs. Remoting nesta postagem do fórum . Para resumir a postagem, ele acaba recomendando o WCF em vez do Remoting.

Não tenho certeza se o .NET 4.0 usa remoting internamente, mas você poderia tentar enviar a Clemens a pergunta ... Tenho certeza que ele sabe a resposta.

— JohannesH
fonte

11

Um funcionário da Microsoft recomendando o uso do novo método novinho em folha, incompatível com tudo o mais, em vez de qualquer forma de padrão? Chocante.

— quillbreaker de

14

De que forma o WCF não é compatível com todo o resto? E o Remoting era compatível com o quê?

— John Saunders de

2

Se você está procurando compatibilidade, o WCF é a escolha -apenas- (exceto asmx, é claro, mas isso também é "legado"). O remoting nunca foi adequado para cenários em que a compatibilidade era um requisito.

— Marcos

3

Aceitei sua sugestão e perguntei a Clemens. Sua resposta: "Remoting é parte do .Net Framework e, como tal, não vai desaparecer ... Para comunicação entre appdomain em processo, Remoting é a forma nativa de comunicação do CLR."

— Marcos

1

Ele prossegue dizendo que você deve "dar uma olhada séria no WCF e na NetNamedPipeBinding."

— John Saunders de

2

Acho que agora (2015) está bastante claro até mesmo para domínios de aplicativos cruzados: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Remoting Cross AppDomains Este tópico é específico para uma tecnologia legada que é mantida para compatibilidade com versões anteriores com aplicativos existentes e não é recomendado para novos desenvolvimentos. Os aplicativos distribuídos agora devem ser desenvolvidos usando o Windows Communication Foundation (WCF).

Então, o WCF deve ser usado também para domínios de aplicativos cruzados.

— Armando
fonte