¿Cómo enviar objetos a través de NamedPipe en .NET 3.5?

Question

¿Puede decirme cuál es la mejor manera de enviar objetos a través de NamedPipes en .net 3.5?

Answer 1

Utilice WCF en un NetNamedPipeBinding. Consulte también Expose a WCF Service through a Named Pipes binding.

Answer 2

serializar el objeto de send it as a text y deserializar en el otro lado, o usar WCF canalizaciones con nombre unión como se sugiere Remus

Answer 3

Lo que se busca es DataContract atributo. Vea también: MSDN Using Data Contracts.

Un contrato de datos es un acuerdo formal entre un servicio y un cliente que describe abstractamente los datos que se intercambiarán. Es decir, para comunicarse, el cliente y el servicio no tienen que compartir los mismos tipos, solo los mismos contratos de datos. Un contrato de datos define con precisión, para cada parámetro o tipo de retorno, qué datos se serializan (convertidos en XML) para ser intercambiados.

Su contrato de servicio:

[ServiceContract] 
public interface IApplicationRegistration 
{ 
    // Sends the application information 
    [OperationContract] 
    bool RegisterApplication(AppInfo appInfo); 
} 

Los datos del Intercambio:

[DataContract] 
public class AppInfo 
{ 
    private int _processID; 
    private string _processName; 

    [DataMember] 
    public int ProcessID 
    { 
     get { return _processID; } 
     set { _processID = value; } 
    } 

    [DataMember] 
    public string ProcessName 
    { 
     get { return _processName; } 
     set { _processName= value; } 
    } 
} 

Answer 4

WCF NetNamedPipes unión es el camino a seguir, también podría considerar .NET Remoting para lograr este

Answer 5

Como comentario sobre la pregunta original señalada, no envía objetos a otros procesos. Puede enviar datos a otro proceso y esos datos pueden usarse para crear un proxy o facsímil del objeto original en el otro proceso, pero no puede enviar directamente un objeto .

Incluso las tecnologías que ofrecen semántica de paso de objetos entre procesos están, bajo el capó, haciendo exactamente eso. Debido a esto, siempre debe usar el estilo de operación "intentar realizar una operación y capturar la excepción si falla" en lugar de "asegurarse de que está bien hacer la operación y luego ejecutarla". Incluso si el objeto parece estar en un estado válido para su operación, está viendo datos antiguos, por lo que puede no ser válido cuando intente realizar la operación real.

Entonces, como no puede enviar objetos, lo que realmente va a terminar es serializar algunos datos (usando XmlSerializer, o DataContractSerializer, o lo que sea), leer el flujo de datos en el otro extremo y crear un nuevo objeto para representar el anterior. Es posible que le resulte más fácil crear un objeto separado para representar los datos que desea enviar a través del conducto, en lugar de la representación real en tiempo real del objeto.

WCF puede manejar muchas de estas cosas automágicamente para usted, pero no hay nada demasiado difícil como para enviarlo a través de una tubería.

Si usa WCF como otros han sugerido, tenga en cuenta que todavía no está enviando "objetos". Todavía está enviando datos, y WCF es bastante explícito al respecto (por eso lo llaman DataContractSerializer, y no ObjectSerializer). Específicamente:

1) Cualquier operación realizada en un objeto enviado con serialización de DataContract se realizará localmente.

2) Si el mismo objeto se envía dos veces, no actualizará automáticamente ninguna versión anterior, y no tendrá igualdad de referencia.Tendrás dos estructuras de datos que, en lo que respecta a C#, no están relacionadas por completo.

3) Las actualizaciones de un objeto sólo se llevarán a cabo a nivel local, y no se actualizarán automáticamente otros procesos con el "mismo" objeto.

Si está absolutamente convencido de que necesita pasar "objetos" a través de los procesos, puede hacer los suyos (lo que de hecho recomendaría, aunque es más trabajo), o usar el espacio de nombres System.Remoting.

Incluso si está utilizando System.Remoting, tenga en cuenta que lo que he mencionado anteriormente es lo que está sucediendo en realidad , y diseñe sus objetos y sistema con eso en mente. Obtendrás resultados mucho mejores.

Answer 6

tuberías asíncrono nombradas aquí http://www.eggheadcafe.com/tutorials/aspnet/478ca475-2fd9-45d6-9090-5acdaeb00162/make-your-apps-talk-to-ea.aspx

utiliza parte de mi código ;-)