バイナリ参照ではなくプロジェクト参照を使用する必要があるのはどのような場合ですか?

Question

私の会社には、サポートするテスト プロジェクトとともに多くのクラス ライブラリ プロジェクトで構成される共通コード ライブラリがあります。各クラス ライブラリ プロジェクトは単一のバイナリを出力します。Company.Common.Serialization.dll。私たちはコンパイル、テストされたバイナリとソース コードを所有しているため、使用するアプリケーションがバイナリ参照を使用するべきかプロジェクト参照を使用すべきかについては議論があります。

プロジェクト参照を支持するいくつかの議論:

• プロジェクト参照により、ユーザーは追加のプロジェクト/ソリューションをロードするオーバーヘッドなしで、すべてのソリューション コードをデバッグおよび表示できるようになります。
• プロジェクト参照は、アクティブなソリューションがなくても変更を簡単に識別できるため、ソース管理システムにコミットされた一般的なコンポーネントの変更を維持するのに役立ちます。

バイナリ参照を支持するいくつかの議論:

• バイナリ参照によりソリューションが簡素化され、ソリューションの読み込み時間が短縮されます。
• バイナリ参照を使用すると、開発者は、すでにベイクされて安定していることが証明されているコードに気を取られる可能性がなくなり、新しいコードに集中できるようになります。
• バイナリ参照を使用すると、組織外のユーザーが行う必要があるのと同じように、共通ライブラリを使用することになるため、適切にドッグフードする必要があります。
• バイナリ参照はデバッグ (ステップイン) できないため、使用側アプリケーションのみのコンテキスト内でテストして修正するのではなく、既存のテスト プロジェクトを拡張して問題を複製して修正する必要があります。
• バイナリ参照では、流入バージョンではなく安定バージョンのバイナリが参照されるため、クラス ライブラリ プロジェクトでの同時開発が使用側アプリケーションに影響を与えないことが保証されます。必要に応じて、コンポーネントの新しいリリースを組み込むかどうかは、プロジェクト リーダーの決定になります。

プロジェクトまたはバイナリ参照の使用に関して、あなたのポリシー/好みは何ですか?

Answer 1

主要なポイントはすべて網羅されているように思えます。最近職場でも同様の議論をしましたが、まだ完全には決まっていません。

ただし、私たちが検討したことの 1 つは、バイナリ ファイルを参照して、あなたが指摘したすべての利点を得る一方で、ソース コードが共通の場所にあり、すべての開発者のマシンからアクセスできる共通のビルド システムによってバイナリをビルドすることです (少なくとも仕事でネットワーク上にある場合は)、必要に応じてデバッグを実際にライブラリ コードに取り込むことができます。

ただし、同時に、デバッガーがそれらを完全にスキップできるようにするために、多くの基本クラスに適切な属性をタグ付けしました。これは、独自のクラス (開発中のレベルで) でデバッグを行うと、基本ライブラリのコードによって大幅にサイズが大きくなるだけです。叩くときにこうする ステップイン ライブラリ クラスのデバッグ ショートカット キーを使用すると、大量のライブラリ コードをくまなく調べる必要がなくなり、現在のレベルの次のコードに再び取り組むことができます。

基本的に、実証済みのライブラリコードを通常の開発者の目につかないようにすることに関するあなたのコメントに (SO 用語で) 間違いなく賛成票を投じます。

また、すべてのプロジェクトと基本的にすべてが含まれるグローバル ソリューション ファイルをロードすると、Visual Studio が実質的に停止するため、ReSharper 4 には何らかの重大な問題があるようです。

Answer 2

私の意見では、プロジェクト参照を使用することの最大の問題は、開発のための共通のベースラインが消費者に提供されないことです。ライブラリが変更されていると思います。その場合は、それらを構築し、バージョン管理されていることを確認すると、簡単に再現可能な環境が得られます。

これを行わないと、参照されているプロジェクトが変更されたときにコードが不可解にも壊れてしまいます。ただし、一部のマシンのみです。

Answer 3

私はこのような一般的なライブラリをサードパーティのリソースとして扱う傾向があります。これにより、ライブラリは独自のビルド プロセス、QA テストなどを持つことができます。QA (または誰か) がライブラリのリリースを「承認」すると、ライブラリはすべての開発者が利用できる中央の場所にコピーされます。その後、バイナリをプロジェクト フォルダーにコピーし、プロジェクト内でバイナリ参照を使用することで、どのバージョンのライブラリを使用するかを各プロジェクトが決定します。

重要なことの 1 つは、ライブラリのビルドごとにデバッグ シンボル (pdb) ファイルを作成し、それらも利用できるようにすることです。もう 1 つのオプションは、実際にネットワーク上にローカル シンボル ストアを作成し、各開発者にそのシンボル ストアを VS 構成に追加させることです。これにより、コード全体をデバッグしながら、バイナリ参照を使用する利点が得られます。

あなたが言及したプロジェクト参照の利点に関しては、私はあなたの 2 番目の点に同意しません。私にとって、使用しているプロジェクトが、使用している共通ライブラリのバージョンを明示的に認識し、そのバージョンをアップグレードするための意図的な手順を実行することが重要です。これは、完了またはテストされていないライブラリへの変更を誤って取得しないようにするための最良の方法です。

Answer 4

ソリューションにそれを含めたくない場合、またはソリューションを分割する可能性がある場合は、すべてのライブラリ出力を共通の bin ディレクトリに送信し、そこで参照します。

これは、開発者がドメイン、テスト、Web プロジェクトのみを含む緊密なソリューションをオープンできるようにするために行いました。当社の Win サービス、Silverlight のもの、および Web コントロール ライブラリは、それらを参照するときに必要なプロジェクトを含む別個のソリューション内にありますが、すべてを構築することはできません。

Answer 5

あなたの質問は、実際には、プロジェクトが同じソリューション内でいつ統合されるかについてのものだと思います。その理由は、同じソリューション内のプロジェクトには相互へのプロジェクト参照が必要であり、異なるソリューション内のプロジェクトには相互へのバイナリ参照が必要であるためです。

私は、ソリューションには密接に連携して開発されたプロジェクトを含めるべきだと考える傾向があります。API アセンブリやそれらの API の実装など。

ただし、親密さは相対的なものです。アプリケーションのデザイナーは、定義上、アプリと密接に関連していますが、デザイナーとアプリケーションを同じソリューション内に配置することは望ましくないでしょう (つまり、それらが少しでも複雑な場合)。おそらく、通常の毎日の統合よりもさらに間隔をあけてマージされるプログラムのブランチに対してデザイナーを開発するとよいでしょう。

Answer 6

プロジェクトがソリューションの一部ではない場合は、そこに含めるべきではないと思います...しかしそれは単なる私の意見です

要するにコンセプトごとに分ける