いつGACにインストールする必要があり、いつインストールしない必要がありますか？（私は、実際には、クライアントが当社の製品を購入したときに、クライアントのマシンにインストールすることを指します）。
1つのアプリケーション（GACまたは非GAC）でのみ使用されるアセンブリがありますか？
すべてのアプリケーションが共有するアセンブリ（GACまたは非GAC）がありますか？
すべてのアプリケーションで、異なるバージョンのアセンブリ（GACまたは非GAC）を使用できますか？
これらは3つのシナリオです...しかし、私はもっとあると確信しています。私は必ずしもこれらの3つの質問だけに対する答えを探しているわけではありません。
同様の質問：GACを使用することの長所と短所は何ですか？
一般的なMSガイドライン
GACは、実際にはMicrosoftの一般的な.NETライブラリのリポジトリです。はい、開発者にも使用させていますが、経験則として、GACが必要ない場合は、使用しないでください。害がなければ、物事をシンプルかつローカルに保ちます。
GACは、パフォーマンス上の理由からのみ検討します。たとえば、巨大なアセンブリがある場合は、それらをGACとNGENに配置してみてください。パフォーマンスが大幅に向上するはずです。Microsoftは、インストール中にすべての標準.NET Frameworkアセンブリに対してこれを実行します（インストールに時間がかかる理由がわかりました）。Paint.NETもそれを行います（アプリの起動時間を改善するため）。ただし、私たちのほとんどは巨大なフレームワークやフォトショップの競合他社に取り組んでいないため、ほとんどの場合、GACでアセンブリを使用することによるパフォーマンスの向上は最小限です。単純なx-copyの展開をあきらめる価値はありません。
一部の開発者は、GACを使用して、権限が不十分なユーザーがアセンブリを削除または変更できないようにする場合があります。
他の人にとってはバージョン管理の理由かもしれませんが、ここでは本当に再考する必要があります。私はすでに言われたことを繰り返すつもりはありません、あなたはなぜここで読むことができます。
また、GACにデプロイする場合は、インストーラーに管理者権限が必要になることを忘れないでください。クリックワンスデプロイメントなどはほとんど忘れることができます。
GAC の有用なケース:
それ以外では、疫病のように GAC を避ける傾向があります。robocopyetcを介してアプリに必要な dll を展開する方がはるかに簡単です。これにより、分離と展開が容易になります。
asp.net Web アプリケーションをインストールしていて、所有者であり、マシンを完全に制御している場合、場合によっては、グローバル アセンブリ キャッシュ内のサイト/Web インスタンス間で共有する予定のアセンブリを配置することが理にかなっている可能性があります。
アセンブリを GAC に配置すると、同じ ASP.NET アプリケーションのインスタンスが複数あるサーバーで、アプリケーションの初期ロード時間とメモリ使用量を大幅に改善できます。少なくとも、何十ものインストールがあるサーバーでこれを見ました。
複数のアセンブリで構成される再利用可能なライブラリを出荷しているが、ファサードを形成しているのはごくわずかである場合、パッケージが開発者のPCにインストールされていれば、アセンブリをGACにインストールすることを検討できます。
想像してみてください。6つのアセンブリを出荷し、これらの6つのアセンブリのうち1つだけにファサードが含まれています。つまり、他の5つはファサード自体によってのみ使用されます。発送します：
プロジェクトを使用している開発者は、自分のプロジェクトでMyProduct.Facade.dllだけを参照したいと考えています。ただし、プロジェクトを実行するときは、参照するすべてのアセンブリを再帰的にロードできる必要があります。これはどのように達成できますか？一般に、それらはGACのBinフォルダーのいずれかで使用可能である必要があります。
注：最後のオプションでは、プロジェクトを実稼働PCに出荷するときに同じことを行うことはできません。すべてのアセンブリをBinフォルダー内に出荷するか、GACにインストールすることができます。すべては希望に応じて異なります。
したがって、説明されているソリューションは、開発中にサードパーティのアセンブリをGACに配置することの利点を示しています。制作とは関係ありません。
お気づきかもしれませんが、GACへのインストールは、主に必要なアセンブリ（依存関係）の場所の問題を解決することを目的としています。アセンブリがGACにインストールされている場合、それは任意のアプリケーションの「近く」に存在すると見なすことができます。これは、.exeへのパスをPATH変数に追加するようなものですが、「管理された方法」で行われます。 -もちろん、これはかなり簡略化された説明です;）
「Avoid the GAC」という Chris Sells のリンクを次に示します。
https://sellsbrothers.com/12503
説明はかなり長いですが、要するに、彼が特定した 2 つのケースは次のとおりです。
影響を受けるアプリに手を加えることなく (そして何も壊さずに) 重大なバグを修正します。
別々にデプロイされたアセンブリ間で実行時に型を共有する
注: Chris の投稿の最後に非常に長いディスカッション スレッドがあり、非常に優れたコメント リストがあります。
まず、これをクライアントマシンにインストールする場合は、GACにアプリをインストールするためのカスタムアクションと、削除するときに別のアクションを追加する必要があります。
ケースAでは間違いなくGACではありません
ケースBでは、ライブラリが絶えず変更される場合は、アセンブリのすべてのバージョンを毎回gacに追加する必要があり、そのアセンブリへの更新が行われます。
ケースCでは、サイドバイサイド実行により、さまざまなアセンブリバージョンを実行でき、バージョンを区別するために何も追加する必要はありません。
本当に必要な場合にのみ使用します