1

ある意味で、ここでベストプラクティスを探しています。

多くのアプリで共有されている共通のプロジェクトがあります。このプロジェクトには、参照として FlurryAnaylics と ATMHud DLL があります。

メイン プロジェクトでこれらの DLL も参照しないと、常にではありませんが、アプリはデバイスへのデバッグ テストで失敗することがよくあります。debug-to-simulator では、これらの DLL をメイン プロジェクトに追加する必要はありません。

問題は、サブ プロジェクトに常にあるメイン プロジェクトに DLL への参照を含める必要があるかどうかです。

4

1 に答える 1

1

可能な限り、アセンブリ (.dll) への参照ではなく、プロジェクト ファイル (csproj ファイル) への参照を使用します。次のような多くのことが簡単になります。

  • コード ナビゲーション (IDE);
  • 自動ビルドの依存関係 (あなたが読んでいるソース コードはあなたがビルドしているものであり、潜在的に非同期のものではありません);
  • ソースレベルのデバッグ (それがなくても、確実に同期できます);
  • (より簡単に) Debug|Release|... 構成を切り替えます。
  • 定義 (または任意のプロジェクト レベルのオプション) を変更します。

例えば

Solution1.sln

  • Project1a.csproj
  • MonoTouch.Dialog.csproj (../Common/MonoTouch.Dialog.csproj へのリンク)

Solution2.sln

  • Project2a.csproj
  • MonoTouch.Dialog.csproj (../Common/MonoTouch.Dialog.csproj へのリンク)

Common.sln

  • MonoTouch.Dialog.csproj

大規模なソリューションでは、これを行うと少し問題が発生する可能性があります (ビルドのパフォーマンス、ファイル全体の検索など)。それらが大きくなればなるほど、誰もがそのすべての部分について知る必要がなくなります。そのため、プロジェクトが追加されるたびに不都合が大きくなる一方で、利点に対する利益は減少します。

たとえば、Mono 内のすべてのフレームワーク アセンブリへの参照は必要ありません (ただし、個人的には、MonoTouch のすべての SDK アセンブリを使用できます ;-)

注: アセンブリ参照を操作しても、デバイスでのデバッグ中にランダムエラーが発生することはありません。このようなテスト ケースを作成できる場合は、バグ レポートに記入してください:-)

于 2012-03-02T01:51:14.527 に答える