アセンブリの参照について

るぷ犬さんの書き込み (2007-02-06 19:51) より:

ここでは、参照設定をプロジェクト単位が推奨と書いてありました。
（その方が、アセンブリの循環参照や、ビルド順序など優位点がということでした。）

しかも、マイクロソフトの情報なので、自分が間違っていたのか、
それとも、プロジェクト毎や、開発環境、開発現場によるものか、
一体、どのような形が良いのでしょうか。

クラス ライブラリなどの修正が発生した時に、適用しやすい (戻しやすい)
VSS で開発しやすい、デバッグ時にライブラリ側の不具合を究明しやすいという観点で、
私もプロジェクト参照をお勧めしています。(ソースを見た方が早いという実装者もいますし)

るぷ犬さんの書き込み (2007-02-06 20:24) より:

じゃんぬねっとさんが挙げられた観点で、それぞれどういうやり方をされているから
やりやすいのでしょうか？
具体例があれば、教えていただけませんでしょうか？

また、

＞デバッグ時にライブラリ側の不具合を究明しやすい

は、アセンブリ参照（DLL）だと、ソースで追えないからでしょうか？

プロジェクト参照だと、アセンブリのバージョン違いや、どのバージョンの共通DLLを使用しているかなどその辺は管理できるのでしょうか？
（COPY LOCALで制御すればいいのでしょうか）

プロジェクト参照について、やり方や、詳しい説明されているHPなどはありませんでしょうか？

やはり、Visual Studio + VSS + プロジェクト参照じゃないでしょうか。


各実装者が、VSS から取得すれば良いわけですから、管理を意識する必要もないですよね。

るぷ犬さんの書き込み (2007-02-07 17:50) より:

特に、各プロジェクトの配下にできた（コピーされた）アセンブリはそのプロジェクトを
実行やビルドをする為だけのものであり、あくまでリンクが張られているのは参照されているプロジェクトというところでしょうか。
（↑突っ込みどころがあるかもしれませんが…。）

ただ、各プロジェクトの配下にアセンブリが増殖するのが、納得いかなかったもので。
（納得いかないというか、どれが最新かなどが分かりづらくなるので。）

依存関係にあるアセンブリは、実行前にビルドされる仕組みになっています。

るぷ犬さんの書き込み (2007-02-08 10:58) より:

あくまでも開発者、の視点で言えばＶＳＳから取ってくる＝最新（のはず）が自分のマシンに入る。
というところで、各開発者では特に気にすることではないということなんですかね。

objフォルダVS.NETが使用するフォルダ。このフォルダを開発者が意識する必要はなく、覚えておく必要もない。だ、そうですね。）

開発者の視点ではなくて、ＳＩやプロジェクト全体での視点で言うと、どうなのでしょうか・。・
ＶＳＳにＤＬＬなどが重複しているとやはり管理がしづらいような。。。

Ａプロジェクト、Ｂプロジェクト、どちらもＣ．ＤＬＬを参照設定しているとして、

Ａプロジェクトは自身の修正があるが、
Ｂプロジェクトには自身の修正が無い場合

⇒それぞれのbin フォルダのＣ．ＤＬＬは更新日付が異なる。（当たり前）

…ただ、Ｂプロジェクトをリコンパイル対象（更新日付がイコールになる）としていれば良いだけの話なのですかね？