Compartir la memoria entre el servicio de Windows y la aplicación, ¿qué es más fácil?

Question

Necesito mi Servicio para actualizar campos en la memoria compartida para que una aplicación cliente los lea y muestre. He encontrado que mi solución actual es ineficaz debido a Session 0 Isolation.

He cambiado el nombre del mutex es en el espacio de nombres global que fija ese elemento, pero no se ve como si el DLL será susceptible de intercambio de información entre sesiones a pesar de una solución a la sesión 0 Aislamiento ser:

"Elija explícitamente el espacio de nombres Local \ o Global \ para cualquier objeto con nombre, como los eventos o la memoria mapeada que el servicio pone a disposición."

No sé qué parte de la dll se puede clasificar como un objeto con nombre y tardará demasiado tiempo en volver a instalarla y recorrerla para comprobar.

Vi los volúmenes de código para los canales con nombre y se suspendió. No quiero crear un archivo que toque el disco, como supongo que se requiere de la solución memoryMappedFile. ¿Se pueden hacer funcionar las secciones compartidas de dlls? De lo contrario, ¿qué es más fácil?

public ref class ServerGUIBridge 
{ 
public: 
#pragma data_seg(".sdata") 
    static int commonIntShouldBeGlobal = 0; 
    static bool hasBeenInitializedMakeMeGlobal = false; 
#pragma data_seg() 
#pragma comment(linker, "/section:.sdata,rws") 

Estoy usando .NET 2.0 así que no WCF por favor.

Answer 1

Un método a menudo pasado por alto de IPC es escribir en el registro. Para los dos miembros de POD que propongo compartir, esta sería la solución ideal. IPC, MSDN, and the registry

Answer 2

Todas las versiones de .NET Framework tienen la función Remoting. Permite invocar métodos en otro dominio de aplicación que puede estar en procesos separados. Consulte MSDN para ejemplos y uso: http://msdn.microsoft.com/en-us/library/kwdt6w2k(v=VS.80).aspx

Answer 3

Sugeriría tuberías con nombre: entonces tiene un aislamiento controlado adecuado entre los dos procesos. Compartir archivos DLL parece estar lleno de peligros.

Las canalizaciones con nombre se documentan en MSDN aquí: http://msdn.microsoft.com/en-us/library/aa365590.aspx

y una utilidad artículo busca .NET 2.0 está aquí: http://www.switchonthecode.com/tutorials/interprocess-communication-using-named-pipes-in-csharp

(Tenga en cuenta que .NET 3.5 y anteriores tiene una clase NetNamedPipeBinding [http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx] eso es parte de WCF)