Condivisione della memoria tra servizio Windows e applicazione, qual è il più semplice?

Question

Ho bisogno del mio servizio per aggiornare i campi nella memoria condivisa per un'applicazione client da leggere e visualizzare. Ho trovato la mia soluzione corrente per essere inefficace a causa di Session 0 Isolation.

ho ribattezzato mutex es nel namespace globale che risolve tale elemento ma non guardare come se la dll sarà suscettibile di condivisione tra le sessioni, nonostante una soluzione per Session 0 Isolation essere:

"Scegliere esplicitamente il namespace Local \ o Global \ per qualsiasi oggetto denominato, ad esempio gli eventi o la memoria mappata resi disponibili dal servizio."

Non so quale parte della DLL possa essere classificata come oggetto con nome e ci vorrà troppo tempo per continuare a re-installarla e passarci attraverso per controllarla.

Ho visto i volumi di codice per i canali denominati ed è stato rimandato. Non voglio creare un file che tocchi il disco come immagino sia richiesto per la soluzione memoryMappedFile. È possibile far funzionare le sezioni condivise di DLL? Altrimenti cosa è più semplice?

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

Sto usando .NET 2.0 quindi non WCF per favore.

Answer 1

Un metodo spesso trascurato di IPC è la scrittura nel Registro di sistema. Per i due membri del POD che propongo di condividere questa sarebbe la soluzione ideale. IPC, MSDN, and the registry

Answer 2

Tutte le versioni di .NET framework dispongono di funzionalità di Remoting. Permette di chiamare metodi in un altro appdomain che può essere in processi separati. Vedere MSDN per esempi e utilizzo: http://msdn.microsoft.com/en-us/library/kwdt6w2k(v=VS.80).aspx

Answer 3

Suggerire pipe denominate: quindi si ha un corretto isolamento controllato tra i due processi. Condividere le DLL sembra pieno di pericoli.

named pipe sono documentate su MSDN qui: http://msdn.microsoft.com/en-us/library/aa365590.aspx

e un utile in cerca NET 2.0 articolo è qui: http://www.switchonthecode.com/tutorials/interprocess-communication-using-named-pipes-in-csharp

(Tenete a mente che .NET 3.5 e soprattutto ha una classe NetNamedPipeBinding [http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx] fa parte di WCF)