- PR -

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

投稿者投稿内容
るぷ犬
常連さん
会議室デビュー日: 2004/11/10
投稿数: 46
投稿日時: 2007-02-06 19:51
いつもお世話になっております。るぷ犬です。


いつもは下記のように構成しています。


販売システム─┬─ assembly 
       │
       └─ source  ─── ソリューション1  ─┬─ プロジェクト1
                              │
                              │
                              ├─ プロジェクト2
                              │
                              │
                              └─ プロジェクト3




  ※assemblyフォルダにはDLLやEXEなど一括保存

  ※sourceフォルダの配下には各プロジェクト単位(csprojやvbproj)



ビルド後の出力先はデバッグ、リリース関係なく、assemblyフォルダにし、

また、各プロジェクトでの参照するアセンブリはassemblyフォルダから
参照しています。

更にどのアセンブリを使用しているか分からなくならない様に、
COPY LOCAをFALSEにしています。

(各自の開発環境でもこういう形をとっています。
 また、本番ではsourceフォルダを除く形で本番に乗せます。
 お客さんの都合にもよりますが…。)


というような形で、やっていたのですが…、


http://www.microsoft.com/japan/msdn/net/bda/tdlg_ch4.aspx

たまたま、見つけたHPにこのような記事がありました。


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



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


長くなりましたが、よろしくお願い致します。

(たしかに、毎回、ビルド順序はモジュール単位で一覧表を作成していました。)
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-02-06 19:58
引用:

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

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

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


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

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
るぷ犬
常連さん
会議室デビュー日: 2004/11/10
投稿数: 46
投稿日時: 2007-02-06 20:24
お早いご返事ありがとうございます。

引用:

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



じゃんぬねっとさんが挙げられた観点で、それぞれどういうやり方をされているから
やりやすいのでしょうか?
具体例があれば、教えていただけませんでしょうか?
(自分は、投稿内容の形しかやったことが無いので、まったく、想像がつきません。。。(汗))


また、

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

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




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


単に、同じ名前の複数のDLLが散らばらなかったり、ビルド順序の管理など
簡単なやり方があれば、そちらの方でやっていきたいと思っています。


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



質問ばかりですみません。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-02-07 14:43
引用:

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

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


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

引用:

また、

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

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


そうですね。

汎用的なライブラリとは別に、業務に特化したライブラリもありますよね。
後者の場合、平行開発したり修正が入ることがありますから、不具合も当然発生します。

引用:

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


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

引用:

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


何通りもある手法ではないので、詳しく解説しているページはないと思います。
私も適当に触っていて見つけ、適当に触ってどんな機能か知ることができました。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
るぷ犬
常連さん
会議室デビュー日: 2004/11/10
投稿数: 46
投稿日時: 2007-02-07 17:50
引用:

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


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





だからこそ、その辺のソースや、アセンブリのバージョンは開発者とすれば、
意識しなくていいわけなんですね。
(自分のほしいタイミングなどで最新を持ってくればいいから?)



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


(↑突っ込みどころがあるかもしれませんが…。)



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




とりあえずはプロジェクト参照とファイル参照の違いや、それぞれの長所、短所は分かりましたので
もうすこし、プロジェクト参照について、触ってみたいと思います。



じゃんぬねっとさん、有難うございました。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-02-07 18:01
引用:

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

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


まあ、最後に実行した時の代物が残っているということですね。
依存関係にあるアセンブリは、実行前にビルドされる仕組みになっています。

引用:

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


確かにコピーされているものなのですが、これは常に最新になります。
それ以上増殖することもないですし、開発中に困ることではないと思いますがいかがでしょうか?

それに、Bin や Obj ディレクトリにも '同じもの' が入っていたりするわけで...
言い出したらキリがなかったりします。

アセンブリの管理は、各々の端末でするものではありません。
これは一時的なものですから、アセンブリどうこうはインストーラで考慮しましょう。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
るぷ犬
常連さん
会議室デビュー日: 2004/11/10
投稿数: 46
投稿日時: 2007-02-08 10:58
またまた、お返事ありがとうございます。


引用:

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



のようですね。
やってみたら、変更がかかっていないものについてはスキップされていました。



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



未だにbin や obj フォルダの違いが分かりません。(汗)

(後で調べてみると、

http://www.atmarkit.co.jp/fdotnet/easyvs/easyvs02/easyvs02_02.html


 binフォルダ  VS.NETのデフォルト設定では、ビルドにより生成されたプログラムは、EXEファイル(実行可能ファイル)
        やDLLファイルとして、このbinフォルダ内に出力される。前回ビルドしたプログラムもこのフォルダ内に
        出力されている。
 
 objフォルダ  VS.NETが使用するフォルダ。このフォルダを開発者が意識する必要はなく、覚えておく必要もない。

だ、そうですね。)




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

例えば、

Aプロジェクト、Bプロジェクト、どちらもC.DLLを参照設定しているとして、

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

⇒それぞれのbin フォルダのC.DLLは更新日付が異なる。(当たり前)


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



開発環境:Visual Studio 2003
開発言語:C# 2003
DB  :SQL SERVER 2005

#いつも、書き忘れてしまいます。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-02-08 11:06
引用:

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

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


最新バージョンで取得した場合は、そうなるので気にしないでしょうね。
古いバージョンを取得する場合は、あえてそのように操作しているから意識しているでしょう。

引用:

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


bin くらいは覚えておいてあげても良いと思いますが、通常は問題ないでしょう。

引用:

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


あえてそうしない限り、VSS に DLL のソースは重複しないと思いますよ。
「差分」 は重複とは言わないと思いますし。

引用:

Aプロジェクト、Bプロジェクト、どちらもC.DLLを参照設定しているとして、

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

⇒それぞれのbin フォルダのC.DLLは更新日付が異なる。(当たり前)

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


アセンブリのバージョン管理というのは、開発途中は VSS でやるべきです。
でないと、何のために VSS で統合管理しているのかわからなくなるじゃないでしょうか?

あえてローカル端末で確認するのは、インストーラを作る時だけじゃないでしょうか?

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌

スキルアップ/キャリアアップ(JOB@IT)