14

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

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

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

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

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

プロジェクトまたはバイナリ参照を使用する際のポリシー/好みは何ですか?

4

6 に答える 6

5

主要なポイントをすべてカバーしているかのように思えます。最近、職場で同様の議論がありましたが、まだ完全には決定されていません.

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

ただし、同じ注意事項として、デバッガーがそれらを完全にスキップするように、適切な属性で多くの基本クラスにタグを付けました。基本ライブラリのコードによってのみ非常に大きくなります。このように、ライブラリ クラスで [ステップ イン]デバッグ ショートカット キーを押すと、大量のライブラリ コードをくまなく調べる代わりに、現在のレベルで次のコード部分に再表示されます。

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

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

于 2008-09-05T19:13:03.727 に答える
2

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

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

于 2008-09-05T19:24:05.167 に答える
2

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

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

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

于 2008-09-05T19:45:16.130 に答える
1

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

これは、開発者がドメイン、テスト、および Web プロジェクトのみを持つタイトなソリューションを開くことができるようにするためです。私たちの勝利サービス、Silverlight のもの、および Web コントロール ライブラリは、それらを見るときに必要なプロジェクトを含む個別のソリューションにありますが、nant はすべてをビルドできます。

于 2008-09-05T19:28:23.347 に答える
1

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

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

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

于 2008-09-05T19:31:24.697 に答える
0

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

要するに概念で分けます

于 2008-09-05T19:26:34.507 に答える