Sto lavorando a un progetto che richiede comunicazione inter-AppDomain-intra-process e inter-process-intra-machine. Sì ... lo so ... NET Remoting è ampiamente considerato una tecnologia legacy ma sto affrontando due problemi molto speciali e forse in questi casi WCF non è un sostituto completo di NET Remoting.NET Remoting e MarshalByRefObject sono davvero morti?
1) la comunicazione inter-dominio di applicazione-intra-processo
L'applicazione su cui sto lavorando inizio e la necessità di cercare e caricare uno su più componenti aggiuntivi. Desidero caricare ogni componente aggiuntivo in un AppDomain separato. Ho bisogno di un modo per creare ciascuna istanza Addin nel suo AppDomain e chiamare alcuni metodi di interfaccia di questa istanza ad un certo punto. Qui NET Remoting è l'unico modo, giusto? Inoltre se vogliamo applicare il paradigma System.Addins, apparentemente basata solo Remoting NET e non contrassegnato come obsoleto ...
2) inter-process-intra-machine comunicazione
Qui posso di sicuro esporre da la mia applicazione è un servizio WCF e chiama questo servizio dal mio cliente utilizzando Named Pipes.
Quello che voglio veramente fare è esporre un modello di oggetto dalla mia applicazione, in modo che la mia applicazione possa essere automatizzata da qualche client NET, proprio come il modello di oggetto di automazione OLE/COM esposto da Excel. Qualsiasi client COM può ottenere un riferimento a un oggetto in Excel.Applicare e interrogare i documenti aperti, aprire alcuni nuovi documenti e così via.
Penso che WCF sia buono per comunicare in modo indipendente dalla piattaforma. Ma in questo caso ho solo bisogno di comunicare dal client Net all'applicazione Net sulla stessa macchina. La filosofia del servizio WCF non consente, a mio avviso, di esporre un modello di oggetto ricco con oggetti, raccolta, campo, membri statici, overload di metodi ... O mi sbaglio?
Si prega di scusare il mio inglese male e la mia domanda forse newbie.