バイナリリファレンスとは対照的なプロジェクトレファレンスをいつ使うべきですか？

Question

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

プロジェクト参照の賛成でいくつかの引数：

• プロジェクトの参照は、ユーザーが追加のプロジェクト/ソリューションをロードするオーバーヘッドなしに、すべてのソリューションコードをデバッグして表示することができます。
• プロジェクト参照は、ソース管理システムにコミットされた共通コンポーネントの変更に対応するのに役立ちます。これは、変更がアクティブなソリューションなしで容易に識別できるためです。

バイナリの参照を支持するいくつかの引数：

• バイナリ参照がソリューションを簡素化し、高速化ソリューションの読み込み時間のためになるだろう。
• バイナリリファレンスでは、既に焼成され安定していることが判明しているコードに気を取られることなく、新しいコードに集中することができます。
• バイナリリファレンスでは、組織外の人が行う必要があるように、共通ライブラリを使用しているので、私たちは適切に犬を食べさせるでしょう。
• バイナリリファレンスはデバッグできないため、既存のテストプロジェクトを拡張して消費するアプリケーションのコンテキスト内でテストして修正するのではなく、問題を複製して修正する必要があります。
• バイナリリファレンスは、バイナリの安定バージョンが流入バージョンではなく参照されるため、クラスライブラリプロジェクトでの同時開発が消費アプリケーションに影響を与えないようにします。必要に応じてコンポーネントの新しいリリースを組み込むかどうかは、プロジェクトリーダーの決定になります。

プロジェクトまたはバイナリの参照を使用する際のポリシー/プリファレンスは何ですか？

Answer 1

すべての大きなポイントをカバーしたように聞こえます。私たちは最近仕事で似たような議論をしてきましたが、私たちはまだ決定していません。

ただし、バイナリファイルを参照してすべての利点を得ることができますが、バイナリは共通のビルドシステムによって構築され、ソースコードは共通の場所にあり、すべてのデベロッパーマシン（少なくとも職場のネットワークに座っている場合）は、必要に応じて、実際にはデバッグがライブラリーコードに潜入することができます。

しかし、同じノートでは、デバッガが完全にスキップするようにするために、多くの基本クラスに適切な属性を付けてタグ付けしました。これは、自分のクラスで行うデバッグ再開発）は、基本ライブラリからのコードによって非常に大きくなるだけです。このようにしてライブラリクラスのステップインデバッグショートカットキーを押すと、ライブラリコードを数多く通過させるのではなく、現在のレベルで次のコードに書き換えます。

基本的には、実証済みのライブラリコードを通常の開発者に見せないようにすることについてのあなたのコメントにはっきりと投票します。

また、ReSharper 4にはすべてのプロジェクトが含まれ、基本的にはすべてのものが含まれているグローバルなソリューションファイルを読み込むと、Visual Studioが実質的に静止しているので、何らかの冠状動脈の問題があるようです。

Answer 2

私の意見では、プロジェクト参照の最大の問題は、消費者に開発の共通ベースラインを提供しないということです。私は図書館が変化していると仮定しています。そうであれば、それらを構築し、それらがバージョン化されていることを確認することで、簡単に再現可能な環境を提供します。

これを行わないと、参照されるプロジェクトが変更されたときにコードが不思議に壊れることになります。しかし、いくつかのマシンでのみ。

Answer 3

ときドン、私は短い

Answer 4

に概念によってそれを分離、私はこのプロジェクトは、ソリューションの一部でない場合、あなたはそこにそれを含めるべきではないと思います...それはちょうど私の意見

ですそれをあなたのソリューションに入れたい、あるいはあなたのソリューションを分割して、すべてのライブラリ出力を共通のbinディレクトリに送って参照することができます。

これは、開発者がドメイン、テスト、およびWebプロジェクトのみを持つ緊密なソリューションを開くために行ったものです。当社の勝利サービス、銀色のもの、およびWebコントロールライブラリは、それらを見ているときに必要なプロジェクトを含む個別のソリューションに含まれていますが、ナントはそれをすべて構築できます。

Answer 5

私はあなたの疑問は、プロジェクトが同じ解決策で一緒になったときのことだと思います。その理由は、同じソリューション内のプロジェクトは互いにプロジェクト参照を持つ必要があり、異なるソリューション内のプロジェクトはお互いにバイナリ参照を持つ必要があるからです。

ソリューションには、緊密に一緒に開発されたプロジェクトが含まれるべきだと思う傾向があります。あなたのAPIアセンブリやそれらのAPIの実装など。

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

Answer 6

このような共通ライブラリを第三者のリソースとして扱う傾向があります。これにより、ライブラリには独自のビルドプロセス、QAテストなどができます。QA（または誰でも）がライブラリのリリースを「祝福」すると、すべての開発者が利用できる中央の場所にコピーされます。バイナリをプロジェクトフォルダにコピーし、プロジェクトでバイナリ参照を使用することによって、どのバージョンのライブラリを使用するかを決定するのは、各プロジェクトまでです。

重要なことの1つは、ライブラリの各ビルドでデバッグシンボル（pdb）ファイルを作成し、それらを使用可能にすることです。もう1つの選択肢は、ネットワーク上にローカルシンボルストアを実際に作成し、各開発者にそのシンボルストアをVS設定に追加させることです。これにより、コードをデバッグしても、バイナリ参照を使用するメリットがあります。

プロジェクト参照の利点については、私はあなたの2番目の点に同意しません。私にとっては、消費しているプロジェクトが消費している共通ライブラリのバージョンを明示的に知っていて、そのバージョンをアップグレードするための意図的なステップをとることが重要です。これは、完了していないかテストされていないライブラリの変更を間違って受け取らないようにするための最良の方法です。