シンプルなメトロアプリを作成しています。同じアプリの非メトロバージョンも作成しています。
私が直面している問題は、VSが通常のクラスライブラリをメトロアプリに参照し、メトロクラスライブラリを通常のアプリに参照することを許可していないことです。
Metroアプリと非Metroアプリの違いは、UIと、互換性のない一部の機能(たとえば、MetroのFilePicker、非MetroのOpenFileDialog)に関連しています。
これはどのように達成できますか?
シンプルなメトロアプリを作成しています。同じアプリの非メトロバージョンも作成しています。
私が直面している問題は、VSが通常のクラスライブラリをメトロアプリに参照し、メトロクラスライブラリを通常のアプリに参照することを許可していないことです。
Metroアプリと非Metroアプリの違いは、UIと、互換性のない一部の機能(たとえば、MetroのFilePicker、非MetroのOpenFileDialog)に関連しています。
これはどのように達成できますか?
違いはあなたが予想するよりも劇的です。彼らは、さまざまな理由で家を掃除し、もはや維持したくないAPIを削除する機会としてWinRTを使用しています。「ポータブルクラスライブラリ」を調べて、VSにターゲットにするように指示したプラットフォームで利用可能なAPIの小さな交差に基づいてdllを作成できるようにします
基本的に、Robert Levyが述べたように、WinRTはWin32ライブラリから完全に分離されています。
実際、Windows 8がARMデバイスで使用されている場合、Win32ライブラリは実質的に存在しません。Internet Explorer 10へのアクセスは制限されていますが(WinRTのみを搭載したインターネットブラウザーは実用的ではありません)、他のすべてのメトロアプリはそうではありません。
x86およびx64のMetroアプリもWin32にアクセスできません。これは、同じアプリケーションがARMと互換性がある必要があると想定されているためです。複雑さを軽減するために、Microsoftは基本的に、すべてのメトロアプリはWinRTにのみアクセスできると述べています。InternetExplorerはその規則の例外です。
私が言おうとしているのは、これです。両方のアプリケーションを別々に開発する必要があります。デスクトップに焦点を合わせたアプリケーションは、完全にデスクトップ上にあります。また、メトロアプリケーションはメトロインターフェースにのみ存在します。
Metro UIは問題ではありません。「内部」を見ると、名前空間とライブラリが同じではないことがわかります=> METROは、Windows7アプリケーションの上の別のレイヤーではありません。本当に2つの環境をターゲットにする場合は、すべてのビジネスオブジェクトを含む単一のクラスライブラリを作成し、すべてのデータベースにアクセスして、このライブラリと呼ばれる2つの異なるアプリケーションを作成します。