また、グローバル アセンブリ キャッシュを使用しなければならない場合や、使用できない場合はありますか?
7 に答える
- GAC からアセンブリをロードすると、オーバーヘッドが少なくなり、アプリケーションが常に正しいバージョンの .NET ライブラリをロードするセキュリティが確保されます。
- GAC の外部にあるアセンブリを ngen にしないでください。パフォーマンスがほとんど向上せず、多くの場合、パフォーマンスが低下することさえあるからです。
- すべての標準 .NET アセンブリは実際には GAC にあり、(インストール中に) 生成されるため、既に GAC を使用しています。
- 独自のライブラリに GAC を使用すると、展開が複雑になります。
- GAC に何かを入れたい場合、ユーザーはインストール中に管理者としてログインする必要があります。これは、多くの種類のアプリケーションにとってかなりの問題です。
つまり、すべてをまとめると、簡単に始めて、後でアセンブリを GAC と NGEN に入れると大幅なパフォーマンスの向上が見られる場合は、それを試してみてください。それ以外の場合は気にしないでください。GAC は、より多くのアプリケーション間でライブラリを共有することが期待されるフレームワークに適しています。99% のケースでは必要ありません。
アドバンテージ:
- アセンブリを更新するための唯一の場所
- 使用するハード ドライブの容量が少し少ない
不利益:
- 1 つの Web サイトのみを更新する必要がある場合は、更新できません。Web サーバー内の他の Web サイトが壊れた状態で終了する可能性があります
推奨事項: GAC は MS や友人に任せてください。ギガバイトは現在非常に安いです。
GAC は、信頼性の低いコード (部分信頼 ASP.NET アプリケーションなど) に代わって特権操作を実行するために昇格されたアクセス許可を必要とするアセンブリでも使用できます。
たとえば、昇格された特権、つまりFull Trustを必要とするタスクを実行する必要がある部分信頼 ASP.NET アプリケーションがあるとします。解決策は、昇格された特権を必要とするコードを別のアセンブリに配置することです。アセンブリはAllowPartiallyTrustedCallers
属性でマークされ、特権ロジックを含むクラスは次のように PermissionSet 属性でマークされます。
[PermissionSet(SecurityAction.Assert, Unrestricted=true)]
アセンブリには厳密な名前が付けられ (署名され)、GAC にデプロイされます。
これで、部分的に信頼されたアプリは、GAC の信頼されたアセンブリを利用して、部分的な信頼の利点を失うことなく、特定の限定的な一連の特権操作を実行できるようになりました。
複数のアセンブリで構成される再利用可能なライブラリを出荷しているが、ファサードを形成するアセンブリはごくわずかである場合、パッケージが開発者の PC にインストールされている場合は、アセンブリを GAC にインストールすることを検討できます。
6 つのアセンブリを出荷し、これら 6 つのアセンブリのうちの 1 つだけにファサードが含まれているとします。つまり、他の 5 つのアセンブリはファサード自体によってのみ使用されます。あなたが出荷:
- MyProduct.Facade.dll - 開発者が使用することを意図した唯一のコンポーネントです
- MyProduct.Core.dll - MyProduct.Facade.dll によって使用されますが、開発者による使用は意図されていません
- MyProduct.Component1.dll - 同じ
- MyProduct.Component2.dll - 同じ
- ThirdParty.Lib1.dll - MyProduct.Component1.dll で使用されるサードパーティ ライブラリ
- ThirdParty.Lib2.dll - 同じ
- 等
あなたのプロジェクトを使用する開発者は、自分のプロジェクトでMyProduct.Facade.dllだけを参照したいと考えています。しかし、プロジェクトの実行時には、参照するすべてのアセンブリを再帰的にロードできる必要があります。これはどのように達成できますか?一般に、これらは GAC の Bin フォルダーで使用できる必要があります。
- 開発者に、インストール フォルダーを見つけて、そこに配置したN 個のアセンブリすべてへの参照を追加するよう依頼することができます。これにより、それらが Bin フォルダーにコピーされ、実行時に使用できるようになります。
- これらの 6 つの参照が既に含まれているVS.NET プロジェクト テンプレートをインストールできます。インストールの前に、アセンブリへの実際のパスをこのテンプレートに挿入する必要があるため、少し複雑です。このパスはインストール パスに依存するため、これはインストーラーによってのみ実行できます。
- 開発者に、必要な依存関係を Bin フォルダーにコピーする.csproj / .vbproj ファイルに特別なビルド後のステップを作成するよう依頼することができます。同じ欠点。
- 最後に、すべてのアセンブリを GAC にインストールできます。この場合、開発者はプロジェクトから MyProduct.Facade.dll への参照のみを追加する必要があります。とにかく、他のすべては実行時に利用可能になります。
注: 最後のオプションでは、プロジェクトを運用 PC に出荷するときに同じことを行う必要はありません。Binフォルダー内のすべてのアセンブリを出荷するか、それらをGACにインストールできます-すべてはあなたの希望次第です.
したがって、説明したソリューションは、開発中にサードパーティのアセンブリを GAC に入れる利点を示しています。制作には関係ありません。
お気づきかもしれませんが、GAC へのインストールは主に、必要なアセンブリ (依存関係) の場所の問題を解決することを目的としています。アセンブリが GAC にインストールされている場合、アプリケーションの "近く" に存在すると見なすことができます。.exe へのパスを PATH 変数に追加するようなものですが、「管理された方法」で行います。 - もちろん、これはかなり簡略化された説明です ;)
GAC は完全な信頼で実行され、Web アプリの外部のアプリケーションで使用できます。たとえば、Sptimer サービスは別のプロセスであるため、Sharepoint のタイマー ジョブは GAC に存在する必要があります。
「完全な信頼」部分も、セキュリティ上の問題の原因となる可能性があります。確かに、コード アクセス セキュリティを使用することはできますが、残念ながら CAS を使用するアセンブリはあまり多くありません :( /bin フォルダーは中程度にロックダウンできますが、通常は問題ありません。
Daniel Larson もCAS に関する記事を投稿しており、違いについてもう少し詳しく説明しています。
GAC を使用する最大の利点の 1 つは、同じアセンブリの複数のバージョンを登録して、アプリケーションで使用できることです。個人的には、マシンからマシンへの移動を制限する方法が好きではありません (新しい VPC でソースをチェックアウトし、それを実行するために一連の手順を実行する必要があると言うのは好きではありません。 GAC)
これまでの人生で、GAC にアセンブリを配置しなければならないアプリケーションがおそらく 1 つありました。これらのアセンブリは、多くのアプリケーションが使用するフレームワークの一部であり、GAC に配置するのが正しいと思われたからです。 .