- PR -

プロジェクトの参照方法について（プロジェクト参照とは）

«前のページへ 1|2
投稿者投稿内容
タオル
常連さん
会議室デビュー日: 2005/04/27
投稿数: 43
投稿日時: 2006-01-29 02:06
お返事遅くなり、申し訳ございません。

囚人さん、
お返事ありがとうございます。
ご提示いただいたURLまだ最初の方しか読み終えてないですが、
引用:
読み解くと頭がすっきりしますよ。

のお言葉の通り、現在はやる気持ちを抑えられない思いでこの時間にPCを立ち上げてしまいました。
しっかり最後まで読ませていただいて、すっきりできたらと思います。
いつも、私の低レベルのお話しに誠実にお付き合いいただき、本当に感謝しております。
早く全体を把握できるようになりたいです。。

ひどりさん、
お返事ありがとうございます。
引用:
(1) と (2) の作業環境＝作業者＋作業端末が同じであればそのとおりです。

この一文で危ないところを救われました。
VS2003のIDEを開いた時、ソリューションエクスプローラに表示されている各プロジェクトなどに、
「鍵」のマークが表示されているので、この時点でVSSの最新ソースを取得しているものだと
勘違いしておりました。

引用:
自分の作業の進捗にあわせて、適宜最新のソースを VSS から取得する方が、私にはあっているようです。

私もです。実はいつも分かっているのか分かっていないのか自分でも分からない状態で、
エラーが起きたとき等の不安感など、とても気持ちが悪かったです。
今後はこの件についての切り分けができそうで、ほっとしています。
ありがとうございました。


じゃんぬねっとさん、
お返事ありがとうございます。
引用:
DLL の参照はその DLL が "完成" されていればそうします。
プロジェクト参照は開発途中である場合に有益です。

これは正に背中を押していただいたような思いです。
このご回答をいただけてよかったです。

引用:
あ、答えるべき場所を間違っているかも。

とんでもないです。私の質問が長々としていて、論点がどこにあるのか
曖昧な文章だなぁと読み返して感じました。
拙い文章でしたが、掻い摘んでご指摘いただき、とてもうれしく思います。

引用:
DLL の場合は見れませんし、開発途中であればその DLL (クラス ライブラリ) を
担当している方がわざわざ固めて VSS にあげなければならないので、手間です。

こちらに関しましては、私の職場では毎日共通DLLの開発者が、固めてVSSにUPするという作業をしています。
何故何故と思いつつ、言い出せなかった事ですので、
私がこれを職場で発言する事はないですが、一つすっきりさせていただきました。
もやもやがあるとどうしても気になってしょうがなくなってしまうので。。

職場では色々な事情で、技術などの事について中々聞きにくい環境にあります。
いつもご迷惑をお掛けしてしまい申し訳ございません。
今後も勉強を続け、じゃんぬねっとさん始め、この世界の先輩方に少しでも近づければという思いです。
今後ともよろしくお願いいたします。


lalupin4さん、
お返事ありがとうございます。
とても分かりやすいご回答いただき、感謝しております。

引用:
「プロジェクト参照とは、自分をビルドする際に、プロジェクト参照しているプロジェクトを自分でリビルドしてDLLを作る」
これは、問題ない、と思います。

とても救われました。
VB6.0で単体アプリしか開発経験が無かったので、
クラスの概念や、新しい開発環境に手間取り、いつも手探りです。
最後の、
引用:
よって、ならないと思います。

というご回答をいただけて、本当にうれしく思います。
いつも中途半端な理解でやっていた面がありまして、
本日やっとすっきりした気持ちになれました。
ありがとうございました。
また、今後何かございましたらぜひよろしくお願いいたします。
タオル
常連さん
会議室デビュー日: 2005/04/27
投稿数: 43
投稿日時: 2006-01-29 04:23
囚人さんへ、
報告。。という訳ではないのですが、
「第2回 アセンブリのアイデンティティ 」を読み終えた所です。
今眠気に限界が来てしまい、寝るところなのですが、
この記事すごいです。
次の、
「第3回 アセンブリのロード 」を読めば
今回の私の質問である、DLLのローカルコピーまわりの疑問が
解消するような気がします。

#自作のDLLは確かに厳密名などありませんでした。。

ありがとうございました。
タオル
常連さん
会議室デビュー日: 2005/04/27
投稿数: 43
投稿日時: 2006-01-29 14:41
お世話になります。


アセンブリのロードを拝見しまして
以下のアセンブリの探索方法を理解しました。
（第3回 アセンブリのロード までしか読み終えていないですが。。）

１　DEVPATH環境変数に列挙されているディレクトリ
２　グローバル・アセンブリ・キャッシュ
３　アセンブリのコードベース
４　3.が存在しなかった場合はプローブを行う

１はそのような設定を行っていないので今の私の問題とは関係ないです。
２もGACに登録していないので関係ないです。
３も自らApp.configを作成していないので関係ないです。
４です。上記の１〜３どれにも当てはまらないので、プローブを行って参照すべきDLLを取得していました。
厳密名やあいまいな名前の以前の問題で、参照設定したDLLのローカルコピーをfalseに設定すると、
１〜４全てで発見できない為、System.IO.FileNotFoundExceptionが発生したという結論に至りました。

紹介していただいた、
http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_03/idnfw11_03_05.html
では、２のGACへの登録と４のプローブについて、推奨しないとあり、その理由も理解できるものでした。

また、
こちらのInsider.NET会議室の過去ログに、
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=11472&forum=7&start=8
１のDEVPATHについても
引用:

GACは色々ありそうなので「どうしようかねー」ということで。
DEVPATH通すのはできました。

まさか、その状態でデプロイしないですよね？ (^^;

とあるとおり、DEVPATHの利用は開発段階だけでのものであると言う事も理解できました。

そうすると私の環境で残された道は、３のアセンブリのコードベース、つまりApp.configの作成しかないのだと考えました。
まず、A画面プロジェクトに構成ファイルの追加を行い、そこに参照している共通DLLへの相対パスの記述を行います。

各画面で参照する共通DLLが一つだけだったとしたら、
このApp.configをファイル名だけ変換して各画面のプロジェクトに
コピーすれば良いかもしれません。
ただ、参照する共通DLLの数は各画面で異なりますので、やはり難しいかと思います。

プロジェクトに参照設定しているDLLをApp.configに自動で記述するような方法は無いのでしょうか？
タオル
常連さん
会議室デビュー日: 2005/04/27
投稿数: 43
投稿日時: 2006-01-29 15:19
引用:
プロジェクトに参照設定しているDLLをApp.configに自動で記述するような方法は無いのでしょうか？

すみません、読み進めましたところ
http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_04/idnfw11_04_04.html
にある、
.NET Framework Configuration管理ツール
で可能になりそうです。
今から熟読します。。
お騒がせして申し訳ございませんでした。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）