MonoTouchおよびMono for Android 固有のライブラリが存在する理由は、多くの場合、(より小さい、Silverlight のような) プロファイルが利用可能であるためです (たとえば、新しい FX4.0 機能に依存するものは切り取る必要があります)。多くの場合、SILVERLIGHT
(またはMONOTOUCH
, MONODROID
) が定義された状態で再コンパイルされた同じコードです。
MonoTouchのみの特定のライブラリの理由は、一般に、その環境 (iOS デバイス) が JIT を許可していないためです。そのため、コード生成 (例System.Reflection.Emit
) やコードの動的 (ダウンロード) ロードはありません...ただし、(パフォーマンスの低い) 回避策を提供したり、いくつかの機能をスキップして、MonoTouch 用のライブラリの特別なバージョンを保持したりすることは、多くの場合可能です。
ここで、単一の共有アセンブリ/プロジェクトに戻ります。特別なMonoTouch アセンブリ (通常、MONOTOUCH
定義済みで再コンパイルされた同じコード) は引き続き有効な.NET アセンブリであり、多くの場合、Mono for Android、Mono、または .NET で使用できます (一度再コンパイルすると、.NET を使用してもMONOTOUCH
)。それは間違いなく最適ではありませんが、試すことができるものです。
もう 1 つは、複数のソリューション (MonoTouchApp、M4AndroidApp など) にわたって同じプロジェクト (MyLib など) を持ち、特別な構成 (iPhone|Debug のものと同じように) を使用して、異なる定義 ( MONOTOUCH
iPhone*|* など) を設定することです。これにより、各プラットフォームで最適な機能の実装を維持できます (たとえば、同じ機能が異なる方法で実装されている場合)。
最初に後で (構成) を試してから、MonoTouch の特別なアセンブリを共有し、最後に (実際に機能しない場合) 他の代替案を探します。