W jaki sposób aplikacja Metro w systemie Windows 8 może komunikować się z aplikacją komputerową zaplecza na tym samym komputerze?

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

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

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.

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ć:

Uznając, że krytyczne funkcje i reguły biznesowe są zawarte w istniejących zasobach oprogramowania i że przedsiębiorstwa mają wiele różnych scenariuszy, w których nowy styl aplikacji będzie wysoce produktywny, aktualizacja systemu Windows 8.1 zawiera nową funkcję o nazwie Brokered Windows Runtime Components do ładowania bocznego Aplikacje. Używamy terminu IPC (komunikacja między procesami) do opisania możliwości uruchamiania istniejących zasobów oprogramowania komputerowego w jednym procesie (komponent pulpitu) podczas interakcji z tym kodem w aplikacji Sklepu Windows. Jest to model znany programistom korporacyjnym, ponieważ aplikacje baz danych i aplikacje korzystające z usług NT w systemie Windows mają podobną architekturę wieloprocesową.

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.

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ć.

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

Aplikacje ze Sklepu Windows nie mogą komunikować się z lokalnymi aplikacjami lub usługami komputerowymi za pośrednictwem mechanizmów lokalnych, w tym plików i kluczy rejestru.

... ale ogranicza tylko „mechanizmy lokalne”. Więc myślę, że można zbudować usługę sieciową do routingu komunikacji.

Jeśli uważasz, że możesz wykonać dodatkową ręczną operację cmd, możesz spróbować:

X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;

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-

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

Zgodnie z projektem aplikacja Metro nie może uzyskać bezpośredniego dostępu do komputera PC, korzystając jedynie z interfejsu API WinRT i dostępnych funkcji. Ale kiedy tworzysz usługę zaplecza, aby uzyskać dostęp do komputera i wszystkich danych, w zasadzie nie działa ona już w piaskownicy.

Jedynym „problemem” jest to, że użytkownik musi ręcznie zainstalować tę usługę zaplecza, ale nie będzie to stanowić problemu przy użyciu „inżynierii społecznej”: użytkownik pobiera aplikację Metro „przeglądarkę na komputery PC”, użytkownik może przeglądać wszystkie zdjęcia, muzykę i filmy , używając interfejsu API WinRT, ale aplikacja wyświetla również komunikat na dole: „Pobierz nasz pakiet do przeglądarki na PC i przeglądaj cały komputer ZA DARMO”

Użytkownik zostaje przekierowany na stronę internetową, skąd może pobrać klasyczny instalator pulpitu zawierający usługę zaplecza „przeglądarki PC”, umożliwiającą dostęp do plików na całym komputerze użytkownika. Po zainstalowaniu tej usługi komputerowej aplikacja Metro może ją wykryć i użyć do przeglądania całego komputera. Użytkownik jest zadowolony, ale piaskownica WinRT jest zagrożona.

Oczywiście to nie zadziała na tabletach z systemem Windows 8 ARM. Korzystając z tego obejścia, można nawet zbudować klientów aplikacji Metro dla klasycznych aplikacji komputerowych, takich jak programy antywirusowe, klienci torrent / P2P itp.

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