私はこれが混乱を招くように聞こえることを知っています..だから私はできるだけ簡潔にしようとしています.
Windows サーバー 2008 R2 に ASP.NET 4 クラシック アプリケーション プールを備えたメイン Web があります。この Web サイト内には、このサイトのすべての管理機能を含むサブ フォルダーがあります。主な開発者は、このサブ フォルダーを別の ASP.NET 4 クラシック アプリ プールに変換することにしました。
基本的に、メインフォルダーをアプリケーションに変換し、サブフォルダーもアプリケーションに変換します。
これまでのところ問題はありませんでしたが、このソリューションが最適なソリューションであるとは確信していません。
これについてあなたの考えを知りたいです。
アプリケーションを独自のアプリケーション プールに分離する理由はたくさんあります。たとえば、別のアプリ プールがある場合、新しい W3WP プロセスが起動されます。つまり、場合によっては、パフォーマンスが向上する可能性があります。新しいプロセスにも独自のメモリ割り当てがあるため、たとえばキャッシュ エントリを上書きしても、メイン サイトのキャッシュ エントリに干渉することはありません (これも問題になる可能性があります)。最後に、そして最も重要なことは、管理者のアプリ プールがクラッシュしても、顧客のメインのアプリ プールには影響しません。多くの場合、アプリの管理セクションは非常に多くの機能が含まれているため、失敗する可能性が最も高くなります (ただし、すべての場合ではありません)。
上記の良いことはすべて、マイナスの影響を与える可能性もあります。たとえば、管理アプリケーションからサイトのフロント エンド部分へのキャッシュ アイテムの有効期限を強制したい場合がありますが、これはより困難になります。また、これらのアプリケーションは、Visual Studio で 2 つの個別のアプリケーションとして分割する必要があります。そうしないと、デプロイが奇妙になります (どちらも同じ bin フォルダー内のアイテムを使用する必要があります)。それがサブディレクトリである場合（あなたが述べたように）、web.configの継承を無効にする必要があります。そうしないと、あらゆる種類の問題が発生します。その方法については、この質問をご覧ください
inheritInChildApplications を使用して、子 Web アプリケーションで web.config の継承を回避する
個人的には、管理セクションのアプリ プールを分割することが有益な場合があると思いますが、それはアプリケーション自体に依存するため、独自のアプリケーションを調べてその決定を下す必要があります。