2

この問題に関するいくつかの議論を見てきましたが、明確な答えはまだ見ていません。確かに、MonoTouch / MonoforAndroidについてはそうではありません。

Xamarinベースのマルチターゲットソリューションを開発していますが、当然、多くの一般的なコードがあります。理想的には、このコードは「共通の」標準.NETクラスライブラリプロジェクト（またはプロジェクト）に存在します。プラットフォーム固有のプロジェクトでこのプロジェクトを参照すると、「プロジェクト'Common'を参照できません。参照されているプロジェクトは別のフレームワークファミリ（.NETFramework）を対象としています」という警告が表示されますが、ソリューションは正常にコンパイルされます。

基本的に、共通のコードが複数のターゲットに対応している場合、ファイルリンクアプローチを使用する必要があるかどうかを尋ねています。より詳細には、私の質問は次のとおりです。

  1. 上記のアプローチは、私の「一般的な」プロジェクトがMono *ターゲットでサポートされているアセンブリのみを参照している場合に有効ですか？
  2. 上記の答えが「はい」の場合：「共通の」プロジェクトでサードパーティの.NETライブラリ（プロジェクトではなくDLLの形式）を参照しているとしましょう。このライブラリには、ターゲットごとに異なるアセンブリがあります（ただし、 Mono *でサポートされていないアセンブリを参照していませんが、Windowsバージョンのアセンブリを参照してそれを回避できますか？
4

2 に答える 2

1

MonoTouchは、Mono for Androidと同様に、通常の（デスクトップ）.NETフレームワークのサブセットを提供します。

このサブセットは、実際にはSilverlight用に出荷された基本クラスライブラリ（BCL）のスーパーセットです（当時はFX 2.1と呼ばれていました）。

バイナリがMonoTouch（またはMono for Android）に存在しないタイプ、メソッド（任意のメタデータ）を参照している場合は、 1または2のいずれかで問題が発生します。

MonoTouchを使用すると、AOT（事前）コンパイルが使用されるため、デバイス用にビルドするときにこのような問題が発生します。IOWの欠落しているシンボルは、ビルド時に検出されます。JITはiOSシミュレーターに使用されるため、実行時に必要になるまで欠落しているシンボルは見つかりません。

Mono for AndroidはJIT（デバイスとエミュレーターの両方）を使用しているため、実行時に欠落しているメタデータが見つかる可能性が高くなります。つまり、マネージリンカーも欠落しているメンバーを検出し、新しい、より小さなアセンブリを作成できなくなります。シンボルを解決できません。

したがって、製品に付属のSDKアセンブリ（BCL）を使用してコードを再コンパイルしない限り、このアプローチは有効ではありません（100％安全です）。

于 2012-09-10T12:23:43.000 に答える
1

しばらくの間、ポータブルクラスライブラリと呼ばれるものがあります。Visual Studio 2012（2012-09-12リリース）以降、Windows 8、Windows Phone、Silverlight、Windows <8などの間でライブラリを共有できるように、VisualStudioの第一級市民になりました。

ポータブルライブラリをMonoforAndroidおよびMonoTouchでも共有できるように、MonoDevelopがこのトラックに従うことを期待しています。

それまでの間、同じソースファイルへのリンクであっても、プラットフォームごとに1つのプロジェクトを作成する必要があります。私はこれが最良の解決策であることがわかりました：

このような名前のプロジェクトファイル

MyCompany.MyProduct.MyModule.Ios.csproj
MyCompany.MyProduct.MyModule.Android.csproj
MyCompany.MyProduct.MyModule.WinPhone.csproj

すべてのプロジェクトの名前空間は、MyCompany.MyProduct.MyModuleのみです。

プロジェクトから「共有」フォルダへの同じcsファイルにリンクします。

Iosバージョンで追加のクラスを公開する必要がある場合は、そのファイルをIosプロジェクト（リンクされていない）に追加し、クロスプラットフォームの名前空間がプラットフォーム固有のもので乱雑にならないようにするため、名前空間に.Iosを追加します。

Windowsパスの長さの問題を壊さないフォルダ構造は次のとおりです。

/MyCompany/MyProduct/

ここに、次のような名前のすべてのターゲットプラットフォームのソリューションファイルを配置します。

MyCompany.MyProduct.Ios.sln
MyCompany.MyProduct.Wpf.sln
...

各アセンブリのフォルダ：

/MyCompany/MyProduct/MyModule/

ここでは、プラットフォームごとに1つの「共有」フォルダーと1つのフォルダーを配置します。

/MyCompany/MyProduct/MyModule/Shared/

クロスプラットフォームコードのみ（各プロジェクトファイルからリンクされています）!!!

/MyCompany/MyProduct/MyModule/Android/
/MyCompany/MyProduct/MyModule/Ios/
/MyCompany/MyProduct/MyModule/WinPhone/
/MyCompany/MyProduct/MyModule/Wpf/
/MyCompany/MyProduct/MyModule/Mac/
...

これは、モジュールの各プラットフォームのプロジェクトファイルを配置する場所であり、特定のプラットフォームにモジュールを実装するために必要なプラットフォーム固有のcsファイルを配置する場所でもあります。

これは私たちにとって非常にうまく機能します。

于 2012-09-13T08:27:34.143 に答える