¿.NET Remoting está realmente en desuso?

95

Todo el mundo está diciendo cómo .NET Remoting está siendo reemplazado por WCF, pero me pregunto qué tan preciso es eso. No he visto ninguna palabra oficial de que Remoting esté siendo desaprobado, y me parece que ciertamente hay escenarios en los que Remoting tiene más sentido que WCF. Ninguno de los métodos o objetos relacionados con Remoting ha quedado obsoleto, incluso en la versión 4.0 del marco. También tengo entendido que System.AddIn en los marcos 3.5 y 4.0 usa Remoting.

¿Alguien tiene alguna palabra oficial que indique lo contrario?

En el artículo, Elegir opciones de comunicación en .NET (para 3.0, ya que esa es la última versión de ese artículo), dice:

8 Comunicaciones de dominio entre aplicaciones

Si necesita admitir la comunicación entre objetos en diferentes dominios de aplicación dentro del mismo proceso, debe utilizar la comunicación remota .NET.

Ahora, eso, por supuesto, no es exacto, ya que WCF ciertamente se puede usar para cruzar los límites del dominio de aplicación, pero ¿está dando la recomendación oficial para ese escenario?

Actualización: le envié a Clemens Vasters (que estaba en el equipo propietario de Remoting y WCF) esta pregunta:

Clemens, tengo entendido que está en el equipo que posee tanto el control remoto como el wcf, y tengo un par de preguntas por las que creo que necesito ir a la fuente.

Primero, tengo una pregunta sobre si la comunicación remota va a desaparecer. Específicamente, tenemos una aplicación bastante grande que utiliza la comunicación remota ampliamente para la comunicación entre dominios de aplicaciones en el proceso, y me preguntaba si este uso de la comunicación remota se considera "heredado". Si es así, ¿AppDomain.CreateInstance y sus amigos serán reemplazados por algo más?

Esta es su respuesta:

La comunicación remota es parte de .Net Framework y, como tal, no va a desaparecer. COM ha estado en Windows desde Windows NT 3.5 / Windows 95 y no ha desaparecido y tampoco veo que eso desaparezca pronto.

Dicho esto, hay una mínima inversión en desarrollo para Remoting. WCF es el sucesor de Remoting y reemplaza COM / DCOM para código administrado.

Para comunicación en proceso, entre aplicaciones y dominios, la comunicación remota es la forma nativa de comunicación de CLR. Si observa problemas de rendimiento al bombear grandes cantidades de datos o muchos mensajes en poco tiempo, debe analizar seriamente WCF y NetNamedPipeBinding.

.net wcf remoting

— marca
fuente

1

Consulte stackoverflow.com/questions/1295353/… para obtener una pregunta sobre por qué WCF es mucho más lento que Remoting en mi situación específica.

— Mark

1

La comunicación remota es intrínseca a .NET, y los detalles del papel que desempeña y cómo funciona se pueden encontrar en Essential .NET por Don Box y Chris Sells. Sin embargo, se desmorona cuando las comunicaciones entre componentes no son confiables o lentas, y prácticamente todos los transportes, incluso una LAN gigabit, no son confiables y lentos en comparación con la mensajería en proceso. Cuando las personas hablan de que WCF es lento, generalmente piensan en servicios web. Los servicios web son demasiado lentos si intenta utilizarlos para las comunicaciones en proceso. Sin embargo, están diseñados para tolerar conexiones lentas y poco fiables y funcionan bien en estas condiciones.

— Peter Wone

3

@Peter: gracias por la información, pero algunas de tus suposiciones son completamente incorrectas. Uno, que la comunicación remota es lenta o poco confiable. No es. Es muy rápido y muy confiable (a través de canales confiables, por supuesto). Otro es que los "servicios web" (lo que sea que eso signifique) son lentos. Ellos no están. Por supuesto, cualquier cosa en proceso será mucho más rápida que cualquier cosa en la red, pero de eso no se trata en absoluto esta pregunta ...

— Mark

54

Llamarla tecnología heredada es una descripción más precisa.

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

Este tema es específico de una tecnología heredada que se conserva para compatibilidad con aplicaciones existentes y no se recomienda para nuevos desarrollos. Las aplicaciones distribuidas ahora deben desarrollarse utilizando Windows Communication Foundation (WCF).

Actualización: WCF no distingue entre inter / intra / process / inter / intra-appdomain. Si está utilizando la comunicación de una sola máquina en WCF, utiliza canalizaciones con nombre; su uso debería ofrecer un buen rendimiento en prácticamente todos los escenarios realistas.

Para una comparación de rendimiento de varias tecnologías de comunicación distribuida, consulte aquí .

— RichardOD
fuente

¿No se refiere ese artículo específicamente al uso de la comunicación remota en la comunicación entre procesos? Me parece que la comunicación remota todavía tiene un lugar en la comunicación entre dominios de aplicaciones (AppDomain.CreateInstanceFromAndUnwrap y amigos).

— Mark

Sí lo es. Si estas clases hubieran sido "obsoletas", se les aplicaría el ObsoleteAttribute: msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx .

— RichardOD

2

@Mark, @RichardOD: El artículo es el artículo principal sobre .NET Remoting. No solo se refiere a la comunicación entre procesos. Además, el hecho de que ObsoleteAttribute no esté en ellos en .NET 3.5 no significa nada, ya que la decisión de anunciar Remoting (y los servicios web ASMX) como "heredados" se tomó después de .NET 3.5 RTM.

— John Saunders

@John: Tampoco están marcados como [Obsoleto] en 4.0 (al menos no todavía).

— Mark

@Mark: te refieres a 4.0 beta 1.

— John Saunders

11

Si. La comunicación remota está en desuso ... y es oficial de Microsoft. Aquí está el enlace:

.NET Remoting

La primera línea del artículo dice en negrita:

Este tema es específico de una tecnología heredada que se conserva para compatibilidad con aplicaciones existentes y no se recomienda para nuevos desarrollos. Las aplicaciones distribuidas ahora deben desarrollarse utilizando Windows Communication Foundation (WCF).

Pensé que la verborrea estaba 'desaprobada' pero aparentemente se refieren a ella como 'legado'

— Justin Niessner
fuente

21

En mi opinión, 'obsoleto' es más fuerte que 'legacy': 'legacy' significa "no iniciar" y obsoleto significa "si ya ha comenzado, deténgase ahora, porque puede eliminarse por completo en versiones futuras".

— ChrisW

1

@Mark: No lo leo de esa manera. WCF parece tan aplicable para la comunicación dentro del proceso como Remoting (consulte NetNamedPipeBinding en WCF).

— Michael Petrotta

1

@Mark: Independientemente, Remoting está en desuso. @ChrisW: Dudo que Remoting se elimine a corto plazo, pero puede esperar menos correcciones de errores, si las hay, y menos soporte, si las hay.

— John Saunders

1

@Mark: ¿cuál es tu verdadera pregunta? La comunicación remota se considera tecnología heredada. Parece que no desea que eso sea cierto. Puede tener buenas razones, pero eso realmente no habla de las recomendaciones actuales de Microsoft.

— Michael Petrotta

1

@John: Supongo que sí. Específicamente, estoy realizando una comunicación entre dominios de aplicaciones en proceso (usando AppDomain.CreateInstanceFromAndUnwrap y amigos), y no veo una manera de hacerlo de manera tan limpia (o de alto rendimiento) usando WCF. En su lugar, estoy feliz de usar WCF (lo uso mucho en otros escenarios), pero para esto tengo problemas para que funcione como quiero. Publicaré otra pregunta sobre ese escenario específico.

— Mark

6

Si desea migrar a .NET Core, debe encontrar otra solución para Remoting de todos modos:

.NET Remoting se identificó como una arquitectura problemática. Se utiliza para la comunicación entre dominios de aplicaciones, que ya no es compatible. Además, Remoting requiere soporte en tiempo de ejecución, que es costoso de mantener. Por estos motivos, .NET Remoting no es compatible con .NET Core y no planeamos agregar soporte para él en el futuro.

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

— Jean Claude
fuente

1

Aquí puede encontrar una discusión sobre las alternativas disponibles en .NET Core: github.com/dotnet/corefx/issues/18394

— Jean-Claude

También mencionado aquí: docs.microsoft.com/en-us/dotnet/core/porting/…

— Jean-Claude

2

Clemens Vasters, el líder técnico de Microsoft .NET Service Bus (que significa tanto Remoting como WCF) habla sobre WCF vs. Remoting en esta publicación del foro . Para resumir la publicación, termina recomendando WCF sobre Remoting.

No estoy seguro de si .NET 4.0 utiliza la comunicación remota internamente, pero podría intentar enviarle la pregunta a Clemens ... Estoy seguro de que conoce la respuesta.

— JohannesH
fuente

11

¿Un empleado de Microsoft recomienda el uso del nuevo método brillante-nuevo-incompatible con todo lo demás sobre cualquier forma de estándar? Impactante.

— Quillbreaker

14

¿De qué manera WCF no es compatible con todo lo demás? ¿Y Remoting era compatible con qué?

— John Saunders

2

Si está buscando compatibilidad, WCF es la única opción (excepto asmx, por supuesto, pero eso también es "heredado"). La comunicación remota nunca fue adecuada para escenarios donde la compatibilidad era un requisito.

— Mark

3

Acepté tu sugerencia y le pregunté a Clemens. Su respuesta: "La comunicación remota es parte de .Net Framework y, como tal, no va a desaparecer ... Para la comunicación entre aplicaciones y dominios en proceso, la comunicación remota es la forma nativa de comunicación de CLR".

— Mark

1

Continúa diciendo que debería "echar un vistazo a WCF y NetNamedPipeBinding".

— John Saunders

2

Creo que ahora (2015) está bastante claro incluso para dominios de aplicaciones cruzadas: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Remoting Cross AppDomains Este tema es específico de una tecnología heredada que se conserva para compatibilidad con aplicaciones existentes y no se recomienda para nuevos desarrollos. Las aplicaciones distribuidas ahora deben desarrollarse utilizando Windows Communication Foundation (WCF).

Entonces WCF también debería usarse para dominios de aplicaciones cruzadas.

— Armando
fuente