Windows8アプリストアに展開するために作成したアプリケーションの移植作業を開始しました。これには、アプリケーションが.NETFrameworkのサブセットに対して作成されている必要があります。私のアプリケーションは、コア機能が独自のdllにあり、ファイルシステムアクセスなどがIoCを介して行われるアーキテクチャに従います。基本的に、これはコアdllの唯一の依存関係がシステムであることを意味します。このため、移植は簡単だと思いました。IoC値を設定し、GUIを接続すれば、準備は完了です。ただ、Windowsストアアプリ（別名メトロアプリ）からコアdllを参照することすらできません。
私は何かを逃したことがありますか？Windows 8アプリストアに含めるためだけにコアdllを実際に書き直す必要がありますか？優れたアーキテクチャを使用すれば、移植は簡単になると言われています。それが私がやったことです。それは大きな嘘でしたか？
Windows ストア アプリ (以前はメトロ スタイル アプリと呼ばれていました) は、.NET Core プロファイルの使用に制限されています。この質問への回答に、コア プロファイルに関する詳細を記載しました。詳細については、この記事の「既存の .NET Framework コードを変換する」を参照してください。これはアーキテクチャではなく、Windows ストア アプリで利用できる .NET Framework のサブセットです。代わりに、.NET で使用する型の一部を WinRT 型で補う必要がある場合があります。
私は幅広い知識を持っていないので、事実を理解した上で事実に固執しようとします。Metroフレームワークは機能を追加し、機能を制限します。厳しいセキュリティ制限があり、利用できない完全な.Netフレームワークの膨大なセグメントがあります（たとえば、System.Dataを使用できない、System.IOおよびファイルアクセス方法の一部が大幅に変更されています）。Metroアプリは分離されているため、標準のアプリケーションのようにハードドライブ上のすべてのファイルを再帰的に実行することはできません（つまり、分離によるセキュリティに加えて、ストレージニーズのためのクラウド）。
状況が変わっていない限り、PInvokeは「承認された」Win32APIメソッドに制限されています。
一般的なWin32APIのニーズに対するいくつかの代替案については、次のリンクを参照してください：http: //msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
承認されたWin32/COM APIについては、次のリンクを参照してください：http: //msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
「優れた」アーキテクチャが、そのアーキテクチャのコードに何が含まれているのかを知らずに、簡単に移植できるかどうかを判断するのは困難です。私のユーティリティフレームワークでは、非常に簡単に移植できるもの（または少なくとも簡単なもの）と、多くの書き直しが必要な完全な洗浄であるものがありました（たとえば、System.Dataの損失は私にとって痛い場所です）。うまく設計できるものもありますが、フレームワークやAPIで下にあるコードを取り出すと、それを使って記述されたものを書き直す必要があります。
私は同じ問題を抱えていました.Metroアプリのプロジェクトは、フレームワーク.4で作成されたdllをロードしません。dll のフレームワークを 4 から 3.5 に変更したところ、Metro プロジェクトでそれらが表示されるようになりました。