Estoy trabajando en un proyecto que requiere una comunicación inter-AppDomain-intra-process e inter-process-in-machine. Sí ... lo sé ... NET Remoting es ampliamente considerada una tecnología heredada, pero estoy enfrentando dos problemas muy especiales y tal vez en estos casos, WCF no es un reemplazo completo de NET Remoting.NET Remoting y MarshalByRefObject está realmente muerto?
1) la comunicación inter-dominio de aplicación intra-proceso
La aplicación que estoy trabajando en el arranque y la necesidad de buscar y cargar uno de los complementos más. Deseo cargar cada complemento en un Dominio de aplicación por separado. Necesito una forma de crear cada instancia de Addin en su AppDomain y llamar a algunos métodos de interfaz de esta instancia en algún momento. Aquí NET Remoting es la única forma, ¿verdad? Por otra parte, si deseamos aplicar el paradigma System.Addins, al parecer basándose únicamente Remoting NET y no marcadas como obsoletas ...
2) entre procesos intra-máquina de la comunicación
Aquí puedo exponer a ciencia cierta desde mi aplicación es un servicio WCF y llamo a este servicio desde mi cliente usando Named Pipes.
Lo que realmente quiero hacer es exponer un modelo de objetos de mi aplicación, para que mi aplicación pueda ser automatizada desde algún cliente NET, al igual que el modelo de objetos de automatización OLE/COM expuesto por Excel. Cualquier cliente COM puede obtener una referencia de objeto a Excel.Aplicar y consultar documentos abiertos, abrir algunos documentos nuevos, etc.
Creo que WCF es bueno para comunicarse de una manera independiente de la plataforma. Pero en este caso solo necesito comunicarme desde el cliente Net a la aplicación Net en la misma máquina. La filosofía de servicio de WCF no permite, creo, exponer un modelo de objeto rico con objetos, colección, campo, miembro estático, sobrecarga de métodos ... ¿O estoy equivocado?
Disculpe mi mal inglés y mi pregunta quizás novata.