Windows 8のMetroアプリは、同じマシン上のバックエンドデスクトップアプリとどのように通信できますか？
Windows 8用の新しいMetroスタイルアプリを使用してUIフロントエンドを構築し、同じローカルマシン上のデスクトップで実行されている.NETアプリケーション（Windowsサービスアプリなど）と通信したい場合。
メトロアプリとデスクトップアプリの間で利用できるプロセス間通信の形式は何ですか？
Visual StudioチームのPavel Minaevに感謝します。VisualStudioチームは、コメントで初期情報を提供してくれました。
Martyn Lovellによれば、そのための意図的なメカニズムはなく、使用できるものは意図的に制限されています。たとえば、名前付きパイプはなく、メモリマップファイルもありません。ソケット（サーバーソケットを含む）がありますが、localhostに接続するときは、同じアプリにしか接続できません。共有された「既知のフォルダ」（ドキュメント、写真など）の1つで通常のファイルを使用できますが、これはかなり粗雑なハッキングであり、ポーリングを必要とし、ユーザーに表示されます。 - Pavel Minaev コメント この問題
したがって、通常のアプローチに失敗すると、Webサービスを使用したり、何らかの形で通信を行うためにデータベースを読み書きしたりすることを考えていました。
ここで私がしようとしていることは理にかなっていますか？メトロアプリが、デスクトップで実行されている既存のサービスのフロントエンドUIになる必要があることがわかります。または、デスクトップ（つまり、非メトロアプリ）で実行されているフロントエンドUIにWPFを使用することをお勧めします。
現在、既存のプロジェクトをWin8に移植しています。 NamedPipes WCFを介して互いに通信しているWindowsサービスとトレイアプリケーションで構成されます。ご存知かもしれませんが、Metroは名前付きパイプをサポートしていません。全二重接続にTcpBindingを使用することになりました。
この投稿 は、サポートされている機能を説明しています。
Metroクライアントが使用できるWCFサーバーのサンプルは、ここです。
また、Metroでは同期WCFを使用できないことに注意してください。非同期のみの Task -basedラッパーを使用する必要があります。
質問ありがとうございます。私にとっては良い出発点でした:)
私が参加した// build /セッションの終わりに、このような多くの質問がありました。ビッグピクチャーセッションの1つを行ったエグゼクティブのAlešHolečekが、聴衆から彼らを処理するために現れました。 C++開発者でない場合でも、そのセッションをダウンロードしてQ＆Aをご覧ください。 http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Metroアプリは、コンピューターにインストールされているデスクトップアプリやサービスを当てにすることはできません。また、デスクトップアプリはいつでも中断できるため、実行中のMetroアプリには当てにできません。別の考え方を始める必要があります。これでアレシュを聞いてください。
Windows 8.1 Updateでは、WindowsストアアプリとC＃for .NET 4.5+で記述されたデスクトップコンポーネント間の通信が、エンタープライズシナリオのサイドロードアプリケーションで公式にサポートされるようになりました。
サイドロードされたWindowsストアアプリ用のWindowsランタイムコンポーネント
引用するには：
重要なビジネス機能とルールが既存のソフトウェア資産に組み込まれており、企業が新しいアプリケーションスタイルの生産性を高めるさまざまなシナリオを持っていることを認識し、Windows 8.1 Updateには、サイドロード用のBrokered Windows Runtime Componentsと呼ばれる新機能が含まれていますアプリケーション。 IPC（プロセス間通信）という用語を使用して、Windowsストアアプリでこのコードを操作しながら、1つのプロセス（デスクトップコンポーネント）で既存のデスクトップソフトウェア資産を実行する機能を説明します。データベースアプリケーションおよびWindowsのNTサービスを利用するアプリケーションは、同様のマルチプロセスアーキテクチャを共有するため、エンタープライズ開発者にとって馴染みのあるモデルです。
このアプローチを実装することは、最初は複雑な面では少しですが、Windowsストアとデスクトップコンポーネントを完全に統合できます。とりあえず、パブリックWindowsストアの認定をパスしないことに注意してください。
追加の手動cmd操作を実行できると思われる場合は、次を試してください。
X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;
CheckNetIsolation.exeはwinRTインストールに含まれているため、追加でインストールするものはありません。
私はそれを試しました：パッケージの更新後でも動作します。
以下に示すとおり： http://msdn.Microsoft.com/en-us/library/windows/apps/Hh780593.aspx
ここでは、アプリのpackageIDを見つける方法について説明します。 http://social.msdn.Microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how- to-get-the-appid-of-a-metro-style-app-
Christophe Nasarreには blogged があり、ローカルファイルを使用してそれを行うかなりハックな方法について書かれています。その結果、デスクトップアプリとWindowsストアアプリ（ブログではDA/WSAと呼ばれます）間の通信が行われ、2つのアプリのUIを切り替える必要がなくなります。彼はまた、プロトコルハンドラーを使用した、もう少しハッキングの少ない手法についてブログを書いています。
DAと通信するWSAを持つことは、ストアによって明示的に禁止されていることに注意してください アプリ認証要件
Windowsストアアプリは、ファイルやレジストリキーなどのローカルメカニズムを介してローカルデスクトップアプリケーションまたはサービスと通信してはなりません。
...しかし、「ローカルメカニズム」のみを制限します。したがって、通信をルーティングするためのWebサービスを構築できると思います。
同じマシン上で、ローカルサービスを使用してMetroアプリからデスクトップアプリに通信することができます。しばらく前に、ローカルサービスを使用してWinRTサンドボックスをバイパスする簡単な「概念実証」を実装しました。それでも、サービスをインストールするための何らかの「ソーシャルエンジニアリング」または直接的なガイドが必要ですが、とにかくそれは可能です。
Windowsストアにこのようなアプリを追加する際の「ローカルサービス」通信に関する認証規則についてはわかりません。
設計により、Metroアプリケーションは、WinRT APIと利用可能な機能のみを使用して、基盤となるPCに直接アクセスできません。しかし、PCとそこにあるすべてのデータにアクセスするためのバックエンドサービスを作成すると、基本的にサンドボックスで実行されなくなります。
唯一の「問題」は、ユーザーがこのバックエンドサービスを手動でインストールする必要があることですが、「ソーシャルエンジニアリング」を使用しても問題にはなりません。ユーザーは「PCブラウザー」Metroアプリをダウンロードし、ユーザーはすべての写真、音楽、ビデオを閲覧できます、WinRT APIを使用しますが、アプリの下部に「PCブラウザーパワーパックをダウンロードして、PC全体を無料で閲覧します」というメッセージも表示されます
ユーザーはWebページにリダイレクトされ、そこからユーザーはPC全体のファイルにアクセスするための「PCブラウザー」バックエンドサービスを含むクラシックデスクトップインストーラーをダウンロードできます。このデスクトップサービスがインストールされると、Metroアプリはそれを検出し、PC全体の閲覧に使用できます。ユーザーは満足していますが、WinRTサンドボックスは危険にさらされています。
もちろん、これはWindows 8では動作しませんARMタブレット。この回避策を使用すると、アンチウイルス、トレント/ P2Pクライアントなどのクラシックデスクトップアプリ用のMetroアプリクライアントを構築することも可能です。
ポイントを見逃したかもしれませんが、プライベートネットワーク機能をアクティブにすると、ローカルIPアドレス（ローカルホストではない）を使用してローカル実行（http）サーバーに接続できます。これにより、winrtアプリがwpfデスクトップアプリと通信するシナリオが可能になります