- PR -

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

1|2 次のページへ»
投稿者投稿内容
ウラタン
常連さん
会議室デビュー日: 2003/07/25
投稿数: 29
投稿日時: 2004-05-11 11:08
こんにちは、.NET初心者です。

現在、VB.NETの環境で、業務ロジック／画面を持つEXEと、共通機能を持つ
クラスライブラリ（DLL）という構成で開発をしています。
ところが、EXEからDLLの参照がうまく行えずに困っています。

開発環境では、参照の追加で「プロジェクト」タブに追加されるのでいいの
ですが、実行環境としては追加できないのでしょうか？
どこかパスの通ったディレクトリにDLLを置いておくようなイメージにした
いのです。

VCで作った素のDLLなら、LIBを作って、DLL本体はPATHが通ったディレク
トリに置けば参照できますし、VBでのOCXなら、REGSRV32.EXEで登録でき
ると思うのですが、.NETではどうすればできるのでしょうか？

作成したクラスライブラリをなんらかのツールで登録すれば、参照設定の
「.NETタブ」に表示されて使用できる・・・
セットアッププロジェクトにDLLを追加すれば、Setup.exe実行時に参照
パスがシステムに追加される・・・
など、そういうイメージの方法ができるのでは、と思うのですが。

EXEと同じディレクトリに入れておけばとりあえず参照してくれますが、
DLL自体はEXE側に入れずに、参照パスのみ設定したいのです。

もしわかる方いらっしゃいましたら、よろしくお願いいたします。
ぢゃん♪
大ベテラン
会議室デビュー日: 2003/06/12
投稿数: 208
お住まい・勤務地: 都内
投稿日時: 2004-05-11 11:32
引用:

ウラタンさんの書き込み (2004-05-11 11:08) より:

DLL自体はEXE側に入れずに、参照パスのみ設定したいのです。
GAC(Global Assembly Cache)への登録でしょう。

ところで、
引用:

作成したクラスライブラリをなんらかのツールで登録すれば、参照設定の
「.NETタブ」に表示されて使用できる・・・
は別の問題です。
ちょっと情報が古い(VS.NET2002時代)のですが、
「VS .NET と VSS を使用したチーム開発 - 第 4 章 依存関係の管理」の中の、
「独自のアセンブリを [.NET] タブに追加するには 」という項目にあります。
とはいえ、これはVS.NET2002時代の情報ですし、そもそもレジストリを触ることになりますので要注意です。

＜追加情報＞
ほぼ同じ内容ですが、「306149 - [INFO] [参照の追加] ダイアログ ボックスにアセンブリを表示する方法」もあります。
でも、やっぱりVS.NET2002が対象で、情報が古いです。

[ メッセージ編集済み 編集者: ぢゃん♪ 編集日時 2004-05-11 11:37 ]
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2004-05-11 12:31
＞開発環境では、参照の追加で「プロジェクト」タブに追加されるのでいいの
＞ですが、実行環境としては追加できないのでしょうか？

プロジェクト参照すれば、.exe をビルドした時に、クラスライブラリの .dll も .exe と同じディレクトリにコピーされていませんか？

.NET 時代は side-by-side が基本なので、その状態で配布するのが原則です。

GAC への配置は慎重に検討しないと、後で泣きを見ます。


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

ウラタンさんの書き込み (2004-05-11 11:08) より:

現在、VB.NETの環境で、業務ロジック／画面を持つEXEと、共通機能を持つ
クラスライブラリ（DLL）という構成で開発をしています。
ところが、EXEからDLLの参照がうまく行えずに困っています。

　もし、１つのソリューションとしてまとめて、Visual SourceSafeで管理することで競合を回避できるなら、それが一番簡単です。

　.NETではDLL-HELLを解消する為、GACに登録してバージョン管理するか、EXEと同じディレクトリにあるDLLのみを参照します。GACの登録は、署名しなければならなかったりなんやかんやがあるので、特に開発中はお勧めしません。開発が終わって「ほぼ誰も触らない」ことが確定したら、登録するのも１つの方法ですが。「新しいスタイル」として、受け入れましょう。。。（消極的な感じもするが）
CHN
ぬし
会議室デビュー日: 2002/03/07
投稿数: 382
投稿日時: 2004-05-11 12:42
こんにちわわわ

私個人的には .dll という拡張子はやめてほしかったです。
特に深い意味はありませんが。

_________________
一郎
ぬし
会議室デビュー日: 2002/10/11
投稿数: 1081
投稿日時: 2004-05-11 12:56
DEVPATH環境変数にパスを設定したり、アプリケーション構成ファイルでパスを指定したりできるみたいですね。
アプリケーション構成ファイルで設定する場合は、厳密名が付いていないとexeのあるフォルダ以下以外はだめらしいですが。

参考：
http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_03/idnfw11_03_01.html
ウラタン
常連さん
会議室デビュー日: 2003/07/25
投稿数: 29
投稿日時: 2004-05-11 13:07
こんにちわわわ。

GACというキーワードと話の流れで、ある程度アーキテクチャがつかめました。
たくさんの助言ありがとうございます。

GACの詳細まではつかんでいませんが、バージョン管理という話から、特定の
フォルダでランタイムリソースを一括管理する仕組み、と把握しています。
名前の重複などを回避したんですね。

>.NET 時代は side-by-side が基本なので、その状態で配布するのが原則です。
>GAC への配置は慎重に検討しないと、後で泣きを見ます。

>GACの登録は、署名しなければならなかったりなんやかんやがあるので、
>特に開発中はお勧めしません。

このあたりの言葉をありがたくいただいておきます。
どうもありがとうございました。
ウラタン
常連さん
会議室デビュー日: 2003/07/25
投稿数: 29
投稿日時: 2004-05-11 17:35
こんばんわ。

えーと、解決しましたので一応報告まで。
GACは色々ありそうなので「どうしようかねー」ということで。
DEVPATH通すのはできました。

１）.NETランタイムの設定で、外部パスを見に行くフラグを立てる。
２）環境変数「DEVPATH」に外部パス（DLLの置き場所）を設定する。

で、従来のDLLのような使い方ができました。

.NETランタイムの設定は「%runtime install path%\Config」以下の
「machine.config」ファイルにてできました。
通常は「C:\WINNT\Microsoft.NET\Framework\v1.0.3705\CONFIG\machine.config」
とかですね。

ここに。
-------------------------------------------------------
<configuration>
<runtime>
<developmentMode developerInstallation="true"/>
</runtime>
</configuration>
-------------------------------------------------------

こんな感じでフラグを立てると、DEVPATHが有効になります。
んで、環境変数DEVPATHに検索ディレクトリ設定すればおっけー。

ただ、検索ディレクトリ、一番最後の１文字を強制削除するみたいです。
「C:\WINNT\system32」と書くと、「C:\WINNT\system3」を探します。
最後の「\」を削除してるつもりなんだろうけど・・・

もしかしたら、「Application1.exe.config」とかを作って置いとけば
アプリごとの設定ができるかも知れませんが、そこまで試してません。

あとはDLL-HELLに気をつけて検討します。
さんくすでした。
1|2 次のページへ»

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