Pracuję nad projektem wymagającym komunikacji między aplikacjami - między procesami i między procesami. Tak ... Wiem ... NET Remoting jest powszechnie uważany za technologię starszą, ale mam do czynienia z dwoma bardzo szczególnymi problemami i być może w tym scenariuszu WCF nie jest pełnym zamiennikiem NET Remoting.NET Remoting i MarshalByRefObject jest naprawdę martwy?
1) komunikacja między AppDomain-intra-process
Aplikacja pracuję na początku i trzeba szukać i obciążenia na więcej dodatków, jeden. Chcę załadować każdy dodatek w oddzielnym AppDomain. Potrzebuję sposobu, aby utworzyć każdą instancję Addin w jego AppDomain i wywołać niektóre metody interfejsu tej instancji w pewnym momencie. Tutaj NET Remoting to jedyny sposób, prawda? Ponadto, jeśli chcemy zastosować paradygmat System.Addins, najwyraźniej oparty tylko NET Remoting i nie oznaczone jako nieaktualne ...
2) inter-process-intra-maszyna komunikacja
Tutaj na pewno mogę wystawiać od moja aplikacja jest usługą WCF i wywołaj tę usługę od mojego klienta za pomocą potoków nazwanych.
Co naprawdę chcę zrobić, to odsłonić model obiektu z mojej aplikacji, aby moja aplikacja mogła zostać zautomatyzowana z jakiegoś klienta NET, podobnie jak model obiektów OLE/COM ujawniony przez Excel. Każdy klient COM może uzyskać odwołanie do obiektu do Excela. Aplikacja i zapytanie o otwarte dokumenty, otwieranie nowych dokumentów i tak dalej.
Myślę, że WCF dobrze się komunikuje w sposób niezależny od platformy. Ale w tym przypadku potrzebuję tylko komunikować się z klienta sieciowego do aplikacji sieciowej na tym samym komputerze. Filozofia usług WCF nie pozwala, jak sądzę, na eksponowanie bogatego modelu obiektów z obiektami, kolekcją, polem, statycznym elementem, przeciążaniem metod ... A może się mylę?
Proszę wybaczyć moje złe pytanie angielskie i moje być może nowicjusz.