.net - dllをGACに登録するか、ASP.NETのbinフォルダーから参照する方がよいですか

Question

答えが「状況によって異なります」の場合、その理由を簡単に説明していただけますか？

Answer 1

GACは、複数のアプリケーション間で共有されるアセンブリを含むことを目的としています。その場合は、アセンブリに厳密な名前を付けて、GACに登録する必要があります。
そうでない場合は、アセンブリをプライベートアセンブリとして保持し、project/dll参照として参照します。

PS：質問のbinフォルダーの部分から実際に参照を取得しませんでした-これはどのbinフォルダーですか？

Answer 2

反対票を引くリスクを冒して、私は世論に直面して飛ぶつもりであり、GACは最後の手段としてのみ使用されるべきであると言います（私が考えることができる1つの例は、あなたがあなたに与えないbiztalkを使用しているときです各アプリケーションのbinフォルダー）。

GACは、最初は複数のアプリケーション間でファイルを共有するための優れた方法のように思われます。しかし、これらのアプリケーションの1つを更新したい場合はどうなりますか？それを利用するサーバー上のすべてのアプリを壊すリスクを冒すか、GACに複数のバージョンを作成する必要があります。GACの複数のバージョンは、個々のアプリにパッケージ化された異なるバージョンよりも優れているわけではありません。実際、もっと混乱していると思います。

Webファームを実行している場合、サーバーごとに1つのGACが発生するため、GACを使用すると、ファームに追加された新しいサーバーへのアプリのデプロイがより複雑になります。また、サーバー上にアセンブリの単一のコピーがあるという利点も失われます。

ただし、今のところ複数サーバーの問題を忘れて、すべて同じアセンブリを使用する10個のアプリを備えたサーバーがあるとします。2つのアプリにのみ影響するこのアセンブリの問題を特定します。10個すべてのアセンブリを更新しますか？つまり、10個すべてをテストする必要があり、他の方法で機能しているいくつかのアプリケーションが破損する可能性がありますか？または、壊れたアプリケーションのアセンブリを更新し、次の開発サイクル中に他のアプリケーションのアセンブリを更新しますか？後者のアプローチを好むなら、GACは避けるべきだと思います。

Answer 3

デフォルトでは、.Netは一致するアセンブリをGACからローカルアプリフォルダーからのアセンブリよりもロードすることを覚えておく価値があります。

さらに、アセンブリが厳密な名前で署名されている場合は、GACからロードする方がパフォーマンスが高くなります。これは、最初にGACにアクセスするために、厳密な名前がチェックされているためです。つまり、アプリが読み込まれるときに再度実行する必要はありません。ローカルフォルダから厳密な名前のアセンブリをロードすると、その固有の名前が毎回チェックされます（時間はかかりませんが、すべてが加算されます）。厳密な名前で署名されたアセンブリのみをGACにインストールできます。そのためには、管理者権限が必要です。