- PR -

VB.NETでのクラスライブラリ配布について

«前のページへ 1|2
投稿者投稿内容
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2004-05-11 21:13
引用:

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


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


_________________
// 渋木宏明 (Hiroaki SHIBUKI)
// http://hidori.jp/
// Microsoft MVP for Visual C#
//
// ＠ＩＴ会議室 RSS 配信中: http://hidori.jp/rss/atmarkIT/
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-05-12 09:05
引用:

渋木宏明(ひどり)さんの書き込み (2004-05-11 21:13) より:
引用:

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


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




　多分、一郎さんが示されたURLだけ読んでいれば、なんのことかわからないだろうから、補足。（つまり、自分がわからなかった）
引用:

MSDNライブラリ「DEVPATH を使用したアセンブリの検索」より：
開発者は、作成する共有アセンブリが複数のアプリケーションで正しく動作することを確認する必要があります。開発時に、グローバル アセンブリ キャッシュにアセンブリを繰り返し配置する代わりに、アセンブリのビルド出力ディレクトリを指す DEVPATH 環境変数を作成できます。


　それで、特に『.NETランタイムの設定は「%runtime install path%\Config」以下の
「machine.config」ファイルにてできました。』ですね。実行環境、つまり顧客のmachine.configという、.NET Frameworkの根本の設定を変更するつもりですか、っつうことですね。

引用:

引用もと同じ：
この設定は、開発時だけ使用してください。ランタイムは、DEVPATH で見つかった厳密な名前付きアセンブリのバージョンを確認しません。単純に、最初に見つかったアセンブリを使用します。


　これをやると、誰かが「System.dll」という名前のDLLを作っていたとして、たまたまそれがDEVPATH内から見つかったとすると、本来使われるはずのGAC内のSystem.dllが使われずに、誰かが作ったニセのSystem.dllが使われ、多くのアプリケーションが動作しなくなる可能性がある、、、と。
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2004-05-12 09:50
引用:

引用:

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

　多分、一郎さんが示されたURLだけ読んでいれば、なんのことかわからないだろうから、補足。（つまり、自分がわからなかった）


フォローどうも

要するに、DEVPATH って名前を見れば想像が付くと思いますが、これはあくまで開発作業の利便を図るものであって、ごく一般的なエンドユーザ環境での実行に使ってはならないものだということです。

運用環境でどのように問題を解決するかは、別途検討する必要があります。

一般解は既に述べたとおり、共通モジュールを

・side-by-side 配置する
・GAC に登録する

などです。

_________________
// 渋木宏明 (Hiroaki SHIBUKI)
// http://hidori.jp/
// Microsoft MVP for Visual C#
//
// ＠ＩＴ会議室 RSS 配信中: http://hidori.jp/rss/atmarkIT/
一郎
ぬし
会議室デビュー日: 2002/10/11
投稿数: 1081
投稿日時: 2004-05-12 09:56
おおう、すいません。
記事に書いてあったので、何も考えずに書き込んでしまいました。

まずウラタンさんの
>どこかパスの通ったディレクトリにDLLを置いておくようなイメージにしたい
というのがどうしてなのかが問題でしょうね。

もし、ウラタンさんのリリースするプログラム全てで共通に使うような機能を持ったdllを配置したいというならGACに置くのが良いと思います。
しかし、「頻繁に変更があるだろうし厳密名付けると面倒だな」と思うようなアセンブリでしたらGACに置くべきではありません。
GACの中のアセンブリもバグフィックス等での変更はあるでしょうが、新しいexeを作るたびに変更になるということは、それほど共通の機能ではないということだからです。
もしそうなら、それぞれのexeと一緒のディレクトリ（あるいはそれ以下）に置くのが無難でしょう。

[ メッセージ編集済み 編集者: 一郎 編集日時 2004-05-12 09:59 ]
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2004-05-12 12:16
引用:

もしそうなら、それぞれのexeと一緒のディレクトリ（あるいはそれ以下）に置くのが無難でしょう。


個人的にはコレが一番お勧めです。
ソース管理さえちゃんと行っていれば、特に困ることもないと思うし。

自作のクラスライブラリを GAC に登録しなければならない強い理由が私には分かりません。

開発作業の後にも先にも面倒ごとが付きまとう割りに、得られるメリットはごくわずかなディスク容量だけな気がして。

_________________
// 渋木宏明 (Hiroaki SHIBUKI)
// http://hidori.jp/
// Microsoft MVP for Visual C#
//
// ＠ＩＴ会議室 RSS 配信中: http://hidori.jp/rss/atmarkIT/
ウラタン
常連さん
会議室デビュー日: 2003/07/25
投稿数: 29
投稿日時: 2004-05-12 13:57
どうもお疲れ様です。

目的を書いてないので少し混乱招いてしまったようで。

EXEと違う場所に置くというのは、開発の局面とリリースの局面両方を
想定しています。
開発局面では頻繁に入れ替えるだろうから、GACにデプロイするのは手間
が多そうだということで、とりあえずやめておきます。

完全な開発中は、.NET上でランタイムを全部自分の場所に引っ張ってきて、
動かしていればいいのですが、結合試験からは、メンバーに
「個別にリリースして結合させる」という感覚を植えつけていくために
あえて違う配布法にしようか、などと考えてまして。
ここは方式的な意味は薄いです。

リリース時はGACにて管理するのが良さそうに思ってはいますが、その後の
入れ替えの手間と、入れ替えをどこの部隊が行うか、その方法のレクチャ
にかかる費用と安易な設定をして事故を起こす可能性とを天秤にかけて、
一番効率が良さそうな手配を行うつもりです。

EXEと同じ場所に置きたくないのは、配布時にSetup.exeのキャビネット
内にDLLを飲み込まない方法も想定したいからです。
（これは別の視点で方法があるとも思いますが。）
また、顧客に「中のEXEの場所を動かさないでね」という説明がどれくら
い通じそうか、などの状況も考えるつもりです。
ショートカットしか触らないように言って同じ場所に入れとければ、それ
が一番楽なので、第一候補はそれですね。

特にどうするのが最適か一概に決めるつもりはなくて、
局面に応じて色んな使い方ができればいいと思っています。

お騒がせしました。
«前のページへ 1|2

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