リファレンスアセンブリはASP.Netのネットワーク共有にあります

Question

ここでは、ネットワーク共有上に配置されたアセンブリのセットからすべての機能を使用できる多数のプログラムがあります。一般的なシステムへの書き込みログ、DB接続文字列、いくつかの一般的なビジネスオブジェクトや関数など

バグフィックスや新機能の導入が容易になるため、この設定が好きです。共有ドライブやアプリケーションごとにアセンブリを更新するだけですそれらは最新です。バイナリ互換性を破る必要がありますか？それは軽く行われていませんが、大きな問題ではありません。新しいバージョン番号の新しいフォルダを追加するだけです。 Subversionは各バージョンがどこにあるかを知っているので、各バージョンで複製されたコードにバグフィックスを展開することができます。おそらくそれが本当に必要であるかどうかを確認するための最初の議論があるかもしれないので、いくつかの変更を1つの新しいセットにバッチすることができますが、これを行う必要はほとんどありません。

これをサポートするために、共通ライブラリの参照を自動的に含むカスタムプロジェクトテンプレートがいくつか用意されています。

最後に質問の肉のため—多くの小さなレガシークラシックASPページをサポートしています。これらは、新しい開発とともに、ゆっくりと.NETに移行しています。他のアプリケーションで使用されているこれらのWebアプリケーションに同じのサポートフレームワークを使用できるようにしたいと考えています。従来の知恵によれば、ASP.NetアプリケーションはGACの外部にあるアセンブリを参照することはできません。または、それ自体の小さな仮想ディレクトリです。したがって、ASP.Netのページで共通のコードを使用するには、Webサーバーとすべての開発者マシンのGACにインストールするだけです。このコードの更新がすべてこれらの場所にも伝播されるようにしてください。私たちはそれが不快であると感じます。

共通コードが存在するネットワーク共有から読み取るために必要なアクセス許可をASPNetアカウントに与えることができ、とにかくこれらのアプリケーション用のカスタムプロジェクトテンプレートを作成することができます（したがって、例えば、web.configやサブクラスでは通常のasp.netページクラスを出発点としています）、結局のところ、現在の場所からこれらのアセンブリを参照できるかもしれないと言っている賢明でない知恵を知っている人はいますか？

Answer 1

私が知る限り、ASP.NETでアセンブリを共有する唯一の方法（コードなし）はGACです（または各サイトのローカルコピーを維持し、それぞれが最新であることを確認してください）。

これは価値がありますが、Webサーバー上のGACにロードするアセンブリを作成する可能性はありますか？

私は、従来の参照やリフレクションによって、共有ドライブ上の他の共有アセンブリのオブジェクトに対するリクエストをマーシャリングするGACに1つのアセンブリを書くことができると考えています。

この方法では、共有フォルダ内のアセンブリに対してメンテナンスの手間が最小限に抑えられ、実際にはGACの単一のアセンブリを最新の状態に保つことだけが心配されます。

...そのアセンブリのコードを記述することは、それが価値があるよりももっと難しいものになりかねません。

Answer 2

Joel、あなたのアプリケーションの設定ファイルのleverage the <codebase> elementはできませんか？ AFAIK、それはUNCの共有を扱います。すでに名前のついたフォルダに新しいアセンブリバージョンを入れているのであれば、新しいバージョンがリリースされたときに適切なconfigファイルを新しい<codebase>要素で更新できるようです。 Subversionフックスクリプト。

バージョン番号を変更せずに更新を行った場合、マシンは既にコピーをダウンロードしており、変更を認識していない可能性があるため、1つのヒッチがあります。