.NETでアセンブリを共有

Question

アプリケーションでは、多数のカスタムビルドライブラリとサードパーティ製ライブラリが使用されていますが、各アプリケーションにはこれらのアセンブリへのプライベートリファレンスがあり、これらのアプリケーションのbinフォルダには参照アセンブリがコピーされます。例えば、アプリケーションAは、log4net.dll、CustomLibA.dll、CustomLibB.dll、およびApplication Bもlog4net.dll、CustomLibA.dll、CustomLibB.dllを参照しています。これらのアセンブリは、次の構造に格納されています。

D：\のinetpub \ wwwrootの\ ApplicationAを\ binに D：\のinetpub \ wwwrootの\ ApplicationBを\ binに

私はこのような構成について、以下の質問があります。

1. を私はこれが作成すると思いますすべてのアプリケーションがこれらのアセンブリをすべてロードし、仮想アドレスの断片化を招くため、アプリケーションと参照の数が増えるにつれ、パフォーマンスの問題が生じます。私の前提は正しい？

2. これらのアプリケーションがすべて共通フォルダのアセンブリを参照し、binフォルダにプライベートコピーを持たないようにアプリケーションを整理できますか？例えば、アセンブリlog4net.dllは、CustomLibA.dll、CustomLibB.dllは次のフォルダに整理されてい

D：\のinetpub \ wwwrootの\アプリ\コモン次のように編成されているアプリケーションによって

と参照

：

D：\のinetpub \ wwwrootの\アプリ\ ApplicationAをが D：\のinetpub \ wwwrootの\アプリ\ ApplicationBを

、これらのアプリケーション内のbinフォルダに共通のアセンブリを持っていません。

これは機能しますか？私はcopy localをfalseに設定してこの処理を試みましたが、「ファイルまたはアセンブリxxxxをロードできませんでした」というメッセージが表示されます。

私はGACを使用できることは知っていますが、展開プロセスの性質上、特定のカスタムビルドライブラリではGACを避けたいと考えています。

ありがとう、 ハリ・クリシュナン。

Answer 1

GACを使用する場合は、パフォーマンスとコードの共有に利点が追加される場合があります。すべてのアプリケーションが共通の共有パスを参照すると、各アプリケーションがアセンブリの独自のコピーをメモリにロードするという事実は変わりません。

共有パスによって得られる唯一の利点は、これらのアセンブリの複数のコピーを展開する必要がないことです。

Answer 2

他のパスをbinやgacではなく他のフォルダで探すために、appdomainの他のパスをいつでも追加することができます。
AppDomain.AddReferencePath

Answer 3

私はGACが一般的なクラスライブラリの最善の策だと思います。引き続き、カスタムライブラリをlocal \ binディレクトリに配置することができます。