W sytuacji, gdy masz frontend UI zbudowany przy użyciu nowego stylu Metro aplikacji dla systemu Windows 8 i chciałbyś, aby komunikował się z aplikacją .NET działającą na pulpicie na tym samym komputerze lokalnym (np. Aplikacja usługi Windows).
Jakie formy komunikacji międzyprocesowej są dostępne między aplikacją Metro a aplikacją komputerową?
Podziękowania dla Pavela Minaeva z zespołu Visual Studio, który w komentarzu podał kilka wstępnych informacji:
Według Martyna Lovella nie ma na to celowego mechanizmu, a niektóre, które można by do tego wykorzystać, są celowo ograniczane. Na przykład nie ma nazwanych potoków ani plików mapowanych w pamięci. Istnieją gniazda (w tym gniazda serwera), ale podczas łączenia się z hostem lokalnym można łączyć się tylko z tą samą aplikacją. Możesz użyć zwykłych plików w jednym z udostępnionych „znanych folderów” (Dokumenty, Obrazy itp.), Ale jest to dość prymitywny hack, który wymaga sondowania i jest widoczny dla użytkownika. - komentuje Pavel Minaev w tej sprawie
Tak więc w przypadku niepowodzenia normalnego podejścia myślałem o użyciu usług internetowych lub czytaniu / zapisywaniu w bazie danych w celu uzyskania jakiejś formy komunikacji, z których oba wydają się przesadą, gdy procesy działają na tej samej maszynie.
Czy to, co tu próbuję, ma sens? Widzę potrzebę, aby aplikacja Metro była frontendowym interfejsem użytkownika dla istniejącej usługi działającej na pulpicie. A może lepiej jest po prostu użyć WPF dla interfejsu użytkownika interfejsu użytkownika działającego na pulpicie (tj. Aplikacji innej niż metro).
Odpowiedzi:
W tej chwili przenoszę mój istniejący projekt na Win8. Składa się z usługi systemu Windows i aplikacji zasobnika, które komunikują się ze sobą za pośrednictwem NamedPipes WCF. Jak być może już wiesz, Metro nie obsługuje nazwanych potoków. Skończyło się na użyciu TcpBinding do połączenia w trybie pełnego dupleksu.
W tym poście opisano, jakie funkcje są obsługiwane.
Przykład mojego serwera WCF, z którego może korzystać klient Metro, znajduje się tutaj .
Należy również pamiętać, że nie można używać synchronicznego WCF w Metro. Będziesz musiał użyć Task -na owijkę, która jest tylko asynchroniczny.
Dziękuję za pytanie. Byłem dla mnie dobrym punktem wyjścia :)
źródło
Pod koniec // budowania / sesji, w której uczestniczyłem, pojawiło się wiele takich pytań. Aleš Holeček, wykonawca, który zrobił jedną z dużych sesji zdjęciowych, wyszedł z widowni, aby się nimi zająć. Nawet jeśli nie jesteś programistą C ++, pobierz tę sesję i obejrzyj pytania i odpowiedzi http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Aplikacje Metro nie mogą liczyć na zainstalowanie aplikacji komputerowych lub usług na komputerze. A aplikacje komputerowe nie mogą liczyć na uruchomione aplikacje Metro, ponieważ można je zawiesić w dowolnym momencie. Musisz zacząć myśleć inaczej. Posłuchajcie tego Aleša.
źródło
localhost
bezpośrednio przez gniazdo TCP, dlaczego miałoby to robić za pośrednictwem WCF?Zwróć uwagę, że dzięki Windows 8.1 Update komunikacja między aplikacjami ze Sklepu Windows i składnikami pulpitu napisanymi w języku C # dla .NET 4.5+ jest teraz oficjalnie obsługiwana dla aplikacji ładowanych z boku w scenariuszach dla przedsiębiorstw:
Obsługiwane przez brokera składniki środowiska wykonawczego systemu Windows dla ładowanych z boku aplikacji ze Sklepu Windows
Cytować:
Chociaż wdrożenie tego podejścia jest początkowo nieco skomplikowane, pozwala na głęboką integrację w Sklepie Windows i składnikach pulpitu. Pamiętaj tylko, że na razie nie przejdzie certyfikacji publicznego Sklepu Windows.
źródło
Jest artykuł na InfoQ o tym, jak budować aplikacje Metro luźno połączonych z obsługą protokołów. Jest to coś, co jest obsługiwane przez Windows od dawna i można by przewidzieć, że aplikacja desktopowa zarejestruje się jako program obsługi protokołu i być może aplikacja metra będzie się komunikować za pośrednictwem tego mechanizmu.
Nie mam pojęcia, czy jest to możliwe, ale warto to sprawdzić.
źródło
Christophe Nasarre napisał na blogu o dość hakerskim sposobie zrobienia tego przy użyciu lokalnych plików. Rezultatem jest komunikacja między aplikacją komputerową / aplikacją sklepu Windows (określaną na blogu jako DA / WSA), bez konieczności przełączania się między interfejsem użytkownika obu aplikacji. Opublikował również na blogu o innej, mniej hakerskiej technice związanej z obsługą protokołów.
Należy pamiętać, że posiadanie WSA, który komunikuje się z DA, jest wyraźnie zabronione przez wymagania certyfikacji aplikacji sklepu
... ale ogranicza tylko „mechanizmy lokalne”. Więc myślę, że można zbudować usługę sieciową do routingu komunikacji.
źródło
Jeśli uważasz, że możesz wykonać dodatkową ręczną operację cmd, możesz spróbować:
CheckNetIsolation.exe jest zawarty w instalacji winRT, więc nie ma nic dodatkowego do zainstalowania.
Wypróbowałem to: działa, nawet po aktualizacji pakietu.
Jak pokazano na: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
Tutaj wyjaśniono, jak znaleźć identyfikator pakietu dla swojej aplikacji: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get- appid-of-a-metro-style-app-
źródło
Na tym samym komputerze można komunikować się z aplikacji Metro do aplikacji na komputer za pomocą usługi lokalnej. Zaimplementowałem jakiś czas temu prosty "dowód słuszności koncepcji", jak ominąć piaskownicę WinRT za pomocą usługi lokalnej. Nadal potrzebuje jakiejś „socjotechniki” lub bezpośredniego przewodnika po instalacji usługi, ale i tak jest to możliwe.
Nie jestem jednak pewien co do zasad certyfikacji komunikacji „usługi lokalnej” przy dodawaniu takiej aplikacji do Sklepu Windows.
Próbka tutaj
źródło
Może przegapiłem punkt, ale po aktywacji funkcji sieci prywatnych mogę połączyć się z lokalnym serwerem działającym (http) przy użyciu lokalnego adresu IP (nie localhost). Umożliwia to mój scenariusz, w którym aplikacja winrt komunikuje się z aplikacją komputerową wpf
źródło