ASP.NETでのdllの配置方法

Question

お世話になります。

ASP.NETのWEBアプリケーションを稼動させる際、C#で作成したｄｌｌを使っています。

参照の追加でdllを追加してサーバーに配置すると/binディレクトリの下にdllをコピーします。

これですと、dllを修正した際、コピー先フォルダが多数になってしまうので、dllを一箇所にコピーして

各WEBアプリケーションは、それを参照するようにしたいのですが、どのように設定したらよいでしょうか？

JavaのCLASSPATHのような仕掛を希望しますが、どなたかご教授をお願い致します。

開発並びに運用環境

VisualStudio2012Professional

サーバー＝WindowsServer2012

Answer 1

「コピー先のフォルダが多数」とはどういう意味でしょうか？ binディレクトリは１つのはずですが。

Answer 2

To: 佐祐理さん

言葉足らずで失礼しました。

多数のWebアプリケーションを配置し、それぞれが同一のdllを参照する場合、

それぞれの/binフォルダにdllをコピーする事になるので、dll修正時は

全部のbinフォルダのdllを上書きする事になります。

ですので、全部のWebアプリケーションが、一箇所に保存したdllを参照するような設定にしたいのです。

Answer 3

同一のdllを参照するWebアプリケーションが多数存在すること自体、何か異常なことに感じます。しかも更新が面倒で質問したくなるほどの更新頻度となると余計に。
本当にWebアプリケーションを分割することが適切なのですか？

質問そのものに愚直に答えるならば、いろいろ方法はあると思いますが、グローバルアセンブリキャッシュに登録することでしょうか。

Answer 4

To: 佐祐理さん

複数のWebアプリケーションについて

　Webアプリケーションについては、検討開始したばかりで良く判っていませんが、今までのVB,Java,C等での開発経験から、なんらかのアプリ単位（今回はWebアプリケーション）に担当分けをするので、複数になります。サブシステム単位（アプリ１０～３０）で１個のWebアプリケーションになるとモアベターと思うのですが、複数人での開発方法論がわかりません。

同一dll参照について

　共通処理を全プログラム（今回はWEbアプリケーション）で使うため、C,Javaでは、そのようなモジュールを作成しました。Javaならclass,Cならdllです。これらは、関係する全プログラムが参照しています。dllは、もともと、そうゆう機能ですよね？プログラム本数は数百本ですので、各プログラムへのコピーを避けたいです。

対応方法について

　できれば、CLASSPATHのような、お手軽な方法論がうれしいのですが、ありますでしょうか？宜しくお願いします。

 

Answer 5

複数のWebアプリケーションについて

　Webアプリケーションについては、検討開始したばかりで良く判っていませんが、今までのVB,Java,C等での開発経験から、なんらかのアプリ単位（今回はWebアプリケーション）に担当分けをするので、複数になります。サブシステム単位（アプリ１０～３０）で１個のWebアプリケーションになるとモアベターと思うのですが、複数人での開発方法論がわかりません。

全然違います。Webアプリケーションはサイト全体で１つです。Webページ間でセッションの共有などがあるため、サブシステム単位ですら区切ることはできません。ソース管理方法については別の話題です。何らかのVCSを導入すべきです。

同一dll参照について

　共通処理を全プログラム（今回はWEbアプリケーション）で使うため、C,Javaでは、そのようなモジュールを作成しました。Javaならclass,Cならdllです。これらは、関係する全プログラムが参照しています。dllは、もともと、そうゆう機能ですよね？プログラム本数は数百本ですので、各プログラムへのコピーを避けたいです。

こちらも違います。.NET Frameworkクラスライブラリを利用する際、dllを参照しているはずですが、数百の参照もしないでしょう？ 無駄にdllを分割しすぎです。

Answer 6

o: 佐祐理さん

複数のWebアプリケーションについて
　御指摘内容を理解しました。こちらのサブシステムがサイトになると思いますので、そのような形で検討を進めたいと思います。

同一dll参照について
　共通化したいdllは１本です。数百画面（２０～３０サイトくらいか・・）から、それを参照したいです。できれば１箇所で管理したいです。

Answer 7

どこか見当違いのような気がしますが・・・

> 共通化したいdllは１本です。数百画面（２０～３０サイトくらいか・・）か
> ら、それを参照したいです。できれば１箇所で管理したいです。

「数百画面」はともかく「２０～３０サイト」（サイトではなくアプリケーション？）というのは本当ですか？　そうだとしても、同時に平行して開発されることはないのでは？

であれば、dll を配布して書き換えてもらってもそれほど手間はかからないと思いますけど。

ASP.NET の既定のフォルダ Bin を使うのにはそれなりのメリットがあります。

ASP.NET Web プロジェクト内の共有コード フォルダー
http://msdn.microsoft.com/ja-jp/library/t990ks23%28v=VS.100%29.aspx

"Bin フォルダーのアセンブリは登録する必要がありません。Bin フォルダーに .dll ファイルが存在するだけで、ASP.NET は認識できます。.dll ファイルを変更し、その新しいバージョンを Bin フォルダーに書き込むと、ASP.NET は更新を検出し、以後の新しいページ要求で、.dll の新しいバージョンを使用します。"

変なこと（失礼）を考えないで素直に Bin フォルダを使うことをお勧めします。

Answer 8

To:SurferOnWwwさん、佐祐理さん

いろいろ御教授ありがとうございました。

WEBの構造を良く判っておらず、ポイントがずれているかもしれませんが、御容赦ください。

また、いわゆるWEBサイトを作るのでなく、業務アプリを作るので、アプリケーションのニュアンスがずれてしまったかもしれません。

教えていただいた事をもとに検討を進めたいと思います。

 

Answer 9

PS

とりあえず、下記の方法で対応する事としました。

１．アプリ毎のbinフォルダにdllを配置する

２．dllの修正時は、全dllを上書きするプログラムで更新する。

御教授ありがとうございました

Answer 10

> WEBの構造を良く判っておらず、ポイントがずれているかもしれませんが、御容赦ください。
> いわゆるWEBサイトを作るのでなく、業務アプリを作るので、
> アプリケーションのニュアンスがずれてしまったかもしれません。

それはどういう意味ですか？　正しい用語を使っているでしょうか？

業務用のアプリであろうと何であろうと、ASP.NET Web アプリであれば dll の配置方法は同じですが。

ポイントがずれているぐらいならともかく、用語は正しくないと話が通じません。特に掲示板では話が通じず、無駄なやり取りをくりかえすばかりで、お互いフラストレーションが溜まります。正しい用語を使えるよう、ある程度知識をつけてから質問するようお願いします。

> とりあえず、下記の方法で対応する事としました。
> １．アプリ毎のbinフォルダにdllを配置する
> ２．dllの修正時は、全dllを上書きするプログラムで更新する。

念のための確認ですが、それは開発時の開発マシンでの話ですよね。運用時の Web サーバーでの話であれば GAC に配置するというのも選択肢になりますが、それは検討した上でのことですか。

Answer 11

To:SurferOnWwwさん

質問は、WEBアプリケーション毎のbinフォルダにdllを配置するのでなく、一箇所に配置できないか？でした。

皆様の御意見を拝聴すると、binに配置したほうがメリットあるとの事でしたし、コピーで対応できるのが、現状の監査方法からも好ましいので、とりあえず上記対応としました。GACについては、詳細に検討しきれないので、とりあえず未対応です。今後、モアベターな方法論を見つけた時は、そちらに切り替えるつもりです。

基本的に１サイト＝１Webアプリケーションで開発するとの事でしたが、これについては認識していませんでした。繰り返しになりますが、当方のニーズからすると、１サイト＝複数サブシステムで、１サブシステム＝１Webアプリケーションになりそう・・・と、現状は思っています。

 

Answer 12

基本的に１サイト＝１Webアプリケーションで開発するとの事でしたが、これについては認識していませんでした。繰り返しになりますが、当方のニーズからすると、１サイト＝複数サブシステムで、１サブシステム＝１Webアプリケーションになりそう・・・と、現状は思っています。

なぜでしょう？ 既に指摘していますが、bikkeさんのいう「サブシステム」間でセッション情報の共有などはないのでしょうか？ 利用者は「サブシステム」単位でログインを繰り返すのでしょうか？

Answer 13

To:佐祐理さん
SEが１０人ほどいて、それぞれが数システムを担当しています。システムのメンテナンスタイミングは、それぞれであり、同期を取れないです。ですので、最低でもシステム単位で開発単位が独立していないと、運用できなくなります。確かにログオンIDのようなセッション情報を共有するので、そこについて何らかの仕掛を考える事になります。WEBアプリケーションとしては、正統的でないかもしれませんが、開発体制の変更より労力が少なくてすみます。
現状では、こう考えています。

Answer 14

開発環境に限った話と思っていましたがそうでもないようですね。

> GACについては、詳細に検討しきれないので、とりあえず未対応です。

少なくとも、Bin と GAC はどういうものか、先に紹介されたページを読むなりして勉強して理解してください。その知識がない状態で、開発環境、運用環境、dll の内容の違い、厳密名の有無に応じてどこに配置するのが適当かを考えても意味がありません。ここで議論するにしても、話が通じず、無駄なやり取りをくりかえすばかりになると思います。

> 繰り返しになりますが、当方のニーズからすると、１サイト＝複数サ
> ブシステムで、１サブシステム＝１Webアプリケーションになりそう・
> ・・と、現状は思っています。

ASP.NET Web アプリの構成・特性などをほとんど理解されてないようですが、その状況で「ニーズ」をサイト/アプリケーション構成や開発体制に適切にブレークダウンできているのでしょうか？

まずは ASP.NET に関する本を読むなどして、体系的に基本的な知識を習得されることをお勧めします。

Answer 15

間違った開発手法であってもご自身のスタイルを変える気はない、ということであれば、それなりの苦労（ファイルコピーが面倒、セッション管理を自力実装する必要がある等）をするだけですが、
であれば、自ら好んで選択されているわけですから、特に今回のファイルコピーなどは、フォーラムで質問する意義はないと思います。特にGACやVCS等を提案しているにもかかわらず聞く耳持たないというのであれば余計に。

Going my way、頑張ってください。